From: Nathaniel Talbott <ntalbott@...>
Date: 2000-12-29T05:07:09+09:00
Subject: [ruby-talk:8191] RE:  Inexplicable core dump

> I have some code that looks like this:
>
> 14	def update(channel, value=nil)
> 15		@channels[channel].each {
> 16			| key, proc |
> 17			if (proc.arity == 0)
> 18				proc.call
> 19			else
> 20				proc.call(value)
> 21			end
> 22		} if ( ! @channels[channel].nil? )
> 23	end
>
> The first time it gets called in my code where proc.arity !=
> 0 (i.e. it goes
> into the else branch) it does one of these:
>
> 	./Tuner.rb:20: [BUG] Segmentation fault
> 	ruby 1.6.2 (2000-12-25) [i686-cygwin]
> 	      0 [sig] ruby 120 stackdump: Dumping stack trace
> to ruby.exe.stackdump
> 	Aborted (core dumped)

Hmmm... well, I have some more info. First of all, the bug came back, so the
blank line fix didn't really fix things. I've dug into it a bit more, and it
looks like I was sort of barking up the wrong tree. Things are core dumping
AFTER the proc returns. Turns out it always core dumps after calling the
same proc. Here's the proc (well, it's really a method; passed with
&method(:resultChanged), which might have some bearing, but I'm not sure):

	def resultChanged(result)
		@result = result
		$defout.write(".")
	end

It's kind of complex, but basically this only fails if I've written
something large out (using puts) somewhere else. The core dump seems to be
caused somehow by the return value value of the method (which is always 1 as
far as I can tell) because this always (at least so far) works:

	def resultChanged(result)
		@result = result
		$defout.write(".")
		return nil
	end

I wish I could narrow it down more than that; I tried putting together a
simple example of the problem, but couldn't get it to fail. C isn't my
forte, nor am I familiar with the Ruby internals, but I'm guessing this is a
bug somewhere in the interpreter.

Let me know if I can provide any more information.


Nathaniel

<:((><
+ - -						+ - -
| RoleModel Software, Inc. &		| EQUIP VI
| The XP Software Studio(TM)		|