[#35027] [Ruby 1.9-Bug#4352][Open] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) — "James M. Lawrence" <redmine@...>

Bug #4352: [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

16 messages 2011/02/01

[#35114] [Ruby 1.9-Bug#4373][Open] http.rb:677: [BUG] Segmentation fault — Christian Fazzini <redmine@...>

Bug #4373: http.rb:677: [BUG] Segmentation fault

59 messages 2011/02/06

[#35171] [Ruby 1.9-Bug#4386][Open] encoding: directive does not affect regex expressions — mathew murphy <redmine@...>

Bug #4386: encoding: directive does not affect regex expressions

9 messages 2011/02/09

[#35237] [Ruby 1.9-Bug#4400][Open] nested at_exit hooks run in strange order — Suraj Kurapati <redmine@...>

Bug #4400: nested at_exit hooks run in strange order

12 messages 2011/02/15

[ruby-core:35082] Re: Bug in system()?

From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2011-02-04 03:21:40 UTC
List: ruby-core #35082
2011/2/3 Anthony Wright <anthony@overnetdata.com>:
> On 03/02/2011 14:01, Luis Lavena wrote:
>>
>> On Thu, Feb 3, 2011 at 10:57 AM, Anthony Wright<anthony@overnetdata.com>
>> rote:
>>>
>>> I've just hit a problem where the system() method to call an external
>>> program failed in a fairly unpredictable way, and I couldn't get any
>>> clues
>>> from within ruby to diagnose the problem. As a result I ended up
>>> debugging
>>> process.c to work out what the problem was.
>>>
>> Please provide which version of Ruby (ruby -v) and which platform
>> you're using (uname -a)
>>
> ruby version is 1.9.2p0 on i686-linux built from source
>
> The system is a custom built system based on linux 2.6.30.1 32 bit
>
> Probably the easiest way to reproduce the problem would be to modify the
> code to replace the fork() call with code that simulates it failing, i.e.
> returns -1 and sets errno to ENOMEM. In other words on line 2481 change:
>
> for (; before_fork(), (pid = fork()) < 0; prefork()) {
>
> to
>
> for (; before_fork(), errno=ENOMEM, (pid = -1) < 0; prefork()) {

It's spec. at least It's documented behavior.

 *  call-seq:
 *     system([env,] command... [,options])    -> true, false or nil
 *
 *  system returns +true+ if the command gives zero exit status,
 *  +false+ for non zero exit status.
 *  Returns +nil+ if command execution fails.
 *  An error status is available in <code>$?</code>.
 *  The arguments are processed in the same way as
 *  for <code>Kernel.spawn</code>.

If fork was failure, we have no way to get child process's exit status because
it wasn't created. If you want to change this behavior, can you please
file a new
feature request?

In This Thread

Prev Next