Michael,

That backtrace is indeed too short.  And, there should be a symbol table if
you built with -g.

When working with a core file, you need to tell gdb where to find the
executable.

Here's a good tutorial:
http://www.network-theory.co.uk/articles/gccdebug.html

Glad to hear that it doesn't take too long to segfault...
You probably can use the corefile you have just by pointing gdb at the ruby
executable
after reading the tutorial.

- brent


Michael King-2 wrote:
> 
> gdb -core core
> bt full
> #0  0xffffe410 in __kernel_vsyscall ()
> No symbol table available.
> #1  0xb7dac9a1 in ?? ()
> No symbol table available.
> 
> I'm thinking that this is much shorter than it should be. This build was
> compiled with -O0 -g.
> 
> At the moment it takes about 10 minutes for the test case to run and
> segfault.
> 
> - Michael
> 
> On Thu, Mar 5, 2009 at 12:28 PM, Brent Roman <brent / mbari.org> wrote:
> 
>>
>> Michael,
>>
>> A 'C'-stack backtrace from gdb would be nice.
>> Trim the top off it if it is deeper than 50 levels or so.
>> The core file would be troublesome, as it will likely be very large
>> and require my duplicating your execution environment to load it.
>>
>> How difficult is it to reproduce the bug there? (seconds or days?)
>> To produce the best stack trace, compile with -O0  -g and
>>  use the "full" qualifier in gdb.
>>
>> - brent
>>
>>
> 

-- 
View this message in context: http://www.nabble.com/MBARI8-patch-fixes-bugs-caused-by-incorrect-volatile-variable-declarations-tp22259357p22361849.html
Sent from the ruby-core mailing list archive at Nabble.com.