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
>
>
> Michael King-2 wrote:
> >
> > by back trace do you mean the output of
> > gdb -core core
> > bt
> >
> > or do you want the actual core file?
> >
> > - Michael
> >
> > On Wed, Mar 4, 2009 at 5:06 PM, Roger Pack <rogerdpack / gmail.com> wrote:
> >
> >> a back trace and ruby -v would be nice.
> >>
> >> > I am having an issue with the MBARI patches. In our app the test suite
> >> has a
> >> > segfault at line 1413 in drb.rb. I am compiling Ruby on Ubuntu 6.06,
> >> 32bit,
> >> > GCC 4.0.3. The segfault shows up when compiling at O2 and O0(zero).
> >>
> >> -=r
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/MBARI8-patch-fixes-bugs-caused-by-incorrect-volatile-variable-declarations-tp22259357p22357591.html
> Sent from the ruby-core mailing list archive at Nabble.com.
>
>
>