[#44036] [ruby-trunk - Feature #6242][Open] Ruby should support lists — "shugo (Shugo Maeda)" <redmine@...>
[#44084] [ruby-trunk - Bug #6246][Open] 1.9.3-p125 intermittent segfault — "jshow (Jodi Showers)" <jodi@...>
[#44156] [ruby-trunk - Feature #6265][Open] Remove 'useless' 'concatenation' syntax — "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
Hi,
(2012/04/09 14:19), Yukihiro Matsumoto wrote:
[#44163] [ruby-trunk - Bug #6266][Open] encoding related exception with recent integrated psych — "jonforums (Jon Forums)" <redmine@...>
[#44233] [ruby-trunk - Bug #6274][Open] Float addition incorrect — "swanboy (Michael Swan)" <swanyboy4@...>
[#44303] [ruby-trunk - Feature #6284][Open] Add composition for procs — "pabloh (Pablo Herrero)" <pablodherrero@...>
[#44329] [ruby-trunk - Feature #6287][Open] nested method should only be visible by nesting/enclosing method — "botp (bot pena)" <botpena@...>
[#44349] [ruby-trunk - Feature #6293][Open] new queue / blocking queues — "tenderlovemaking (Aaron Patterson)" <aaron@...>
On Sat, Apr 14, 2012 at 10:58:12AM +0900, mame (Yusuke Endoh) wrote:
Hi,
On Mon, Apr 16, 2012 at 06:25:59PM +0900, SASADA Koichi wrote:
[#44372] Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125? — "Blythe,Aaron" <ABLYTHE@...>
tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Issue 4651. Please advise if this is the same issue, or if a separate issue needs to be logged. Details below.
[#44431] [Backport93 - Backport #6314][Open] Backport r35374 and r35375 — "drbrain (Eric Hodel)" <drbrain@...7.net>
[#44432] [ruby-trunk - Feature #6315][Open] handler to trace output of each line of code executed — "ankopainting (Anko Painting)" <anko.com+ruby@...>
[#44533] [ruby-trunk - Bug #6341][Open] SIGSEGV: Thread.new { fork { GC.start } }.join — "rudolf (r stu3)" <redmine@...>
Hello,
On Mon, Apr 23, 2012 at 11:17 PM, Yusuke Endoh <mame@tsg.ne.jp> wrote:
Hello,
(4/24/12 6:55 AM), Yusuke Endoh wrote:
> kosaki (Motohiro KOSAKI) wrote:
[#44540] [ruby-trunk - Bug #6343][Open] Improved Fiber documentation — "andhapp (Anuj Dutta)" <anuj@...>
[#44612] [ruby-trunk - Feature #6354][Open] Remove escape (break/return/redo/next support) from class/module scope — "ko1 (Koichi Sasada)" <redmine@...>
[#44630] [ruby-trunk - Feature #6361][Open] Bitwise string operations — "MartinBosslet (Martin Bosslet)" <Martin.Bosslet@...>
On Fri, Apr 27, 2012 at 8:53 PM, MartinBosslet (Martin Bosslet)
On Saturday, April 28, 2012 at 8:52 AM, KOSAKI Motohiro wrote:
[#44636] [ruby-trunk - Bug #6364][Open] Segmentation fault happend when running test_cptr.rb — "raylinn@... (ray linn)" <raylinn@...>
[#44667] possible YAML bug in ruby 1.9.3p125? — Young Hyun <youngh@...>
YAML in ruby 1.9.3p125 seems to have a bug reading in YAML from older Ruby versions. Specifically, YAML in 1.9.3p125 mis-parses text like "123_456" as a number (just as in Ruby) rather than as a string, which appears to be the correct behavior according to the YAML specification.
[#44686] [BUG] not a node 0x07 — ronald braswell <rpbraswell@...>
Running ruby 1.8.6 on Solaris 10.
2012/4/28 ronald braswell <rpbraswell@gmail.com>:
I have heard reports of this on 1.9.x. Do you know if this problem has
[#44704] [ruby-trunk - Feature #6373][Open] public #self — "trans (Thomas Sawyer)" <transfire@...>
Issue #6373 has been updated by Marc-Andre Lafortune.
[#44743] [ruby-trunk - Feature #6375][Open] Python notation for literal Hash — "alexeymuranov (Alexey Muranov)" <redmine@...>
[#44748] [ruby-trunk - Feature #6376][Open] Feature lookup and checking if feature is loaded — "trans (Thomas Sawyer)" <transfire@...>
On Thu, May 3, 2012 at 6:02 AM, mame (Yusuke Endoh) <mame@tsg.ne.jp> wrote:
[ruby-core:44627] [ruby-trunk - Bug #6358] arm-linux : sleep() time dependent threading bug
Issue #6358 has been updated by stevegoobermanhill (stephen gooberman-hill).
Hi Yusuke-san,
I'm not sure that I will be able to create a patch - you can blame Matz :-) If he hadn't written such a brilliant language I would still be competent in C. :-) As it is, while I can still competently read and understand C code, I don't think I have written any since about 2003.
Thinking about the problem a bit, my suspicion is that somewhere (either in ruby, or the pthreads library, or in the interaction between them), a thread is being reused before it is properly torn down, and this is causing the problem. A gross simplification of the code (which I have yet to try and use to reproduce the bug) is
timeout=0.01 #this is the critical value
while true
Thread.new do
Thread.new { sleep(timeout) }
end
end
My reasoning is that the bug may be quite deep as it generally exits without giving any backtrace, and is very dependent on the critical value. I don't know about the deep design of the ruby code or the pthreads library, but I am wondering whether it is possible that the there is a timer used to give the system time to tidy up before a thread is reused, and that this timer simply times out too quickly for the platform.
Are you aware of any similar problem on a slower (embedded) platform? It may be a problem that is specific to arm-linux, or to the ulibc pthreads library, or one that only turns up on slow processors.
In the mean time, I will see if I can produce a simple test case which demonstrates the problem. That would be a start.
FYI, I am putting a significant number of embedded arm-linux devices into the field this year (on the Techbase NPE series GPRS modem / industrial computer). I would be happy to continue to contribute bug reports - I have ruby 1.8.7 working happily on this device, but 1.9 is a little more challenging at the moment. Anything that I can contribute, I will do so.
Kind regards,
Steve
----------------------------------------
Bug #6358: arm-linux : sleep() time dependent threading bug
https://bugs.ruby-lang.org/issues/6358#change-26201
Author: stevegoobermanhill (stephen gooberman-hill)
Status: Feedback
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 1.9.2p136 (2010-12-25 revision 30365) [arm-linux]
Hi,
I have a multi-threading bug on a low-speed (180MHz) arm-linux platform. The bug can be consistantly produced or removed by varying the length of a sleep() interval at the end of a piece of code invoked in a Thread (the GServer#serve(io) method)
I am unable to completely isolate the bug, and the trace I get off it is intermittent, but when it occurs it terminates the program instantly. The debugging info that I get when the program fails is dependent on the sleep timer.
I have once seen a ruby fault, with a control frame backtrace (3 levels) showing a cfp consistancy fault (sorry - not sure which one, but send I think - my fault for losing the trace). However, I can consistently get a trace claiming a ThreadError
The lines referenced are marked in the code.
OK - the following piece of code (log statements removed) is taken from a class derived from GServer, and implements the #serve method. The line marked with the arrow (==>) at the bottom is critical in controlling the appearance of the bug.
The bug can be made to appear by running a sequence of unit tests to stress this piece of code (there are 5 test methods in the sequence)
- If the sleep length is 0.01, the program (a test suite) will crash on the first test, with no backtrace or debugging info
- If the sleep length is 0.1, or if the sleep length is 0.01 AND ruby is invoked with --debug then the program will crash at a variable point
in the test sequence, giving the following trace
Exception `ThreadError' at /mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:88 - must be called with a block
must be called with a block
Exception `ThreadError' at /mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:118 - must be called with a block
/mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:88:in `initialize'
/mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:88:in `eof'
/mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:88:in `serve'
This sleep length has also (once) given some control frame information.
- If the sleep length is 0.5, the test sequence will always run correctly.
I suspect that the issue is somewhere deep in the Thread handling code - possibly the ruby interpreter is not giving the underlying linux system enough time to clear up and reallocate threads; this results in the crash.
Hope this is of some help. I do have a workaround at this point (lengthen the timer to 0.5s), but this may be an issue on slower platforms.
Kind regards
Steve
====================== simplified code (/mnt/nand-user/trident_v1.1_alpha/lib/rmodbus/tcp_multi_server.rb:88) ===================
====================== lines referred to in error are commented ===================
====================== sleep statement which can trigger or remove the bug marked with ==> ===================
class TCPMultiServer < GServer
def serve(io)
begin
io.sync=true
io.fcntl(Fcntl::F_SETFL, io.fcntl(Fcntl::F_GETFL) | Fcntl::O_NONBLOCK)
while not stopped?
req=nil
unless io.eof #line 88 (referenced in ThreadError)
req = io.read(7)
destination=req.getbyte(6)
multicast= ( destination == 0 ) #true if multicast message
active_devices= multicast ? @devices.values : [@devices[destination]]
active_devices.compact!
tr = req[0,2]
len = req[4,2].unpack('n')[0]
req = io.read(len - 1) unless io.eof
active_devices.each do |device|
pdu = device.serve(req)
resp = tr + "\0\0" + (pdu.size + 1).to_word + device.uid.chr + pdu
io.write resp
end
end
==> sleep(0.01)
end
rescue Exception => ex
STDERR.puts ex
raise ex #line 118 (referenced in ThreadError)
end
end
end
--
http://bugs.ruby-lang.org/