From: Michael King Date: 2009-03-06T06:37:43+09:00 Subject: [ruby-core:22688] Re: MBARI8 patch fixes bugs caused by incorrect volatile variable declarations --00221532cf6cd3ad67046465ff5a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 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. > > > --00221532cf6cd3ad67046465ff5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable gdb -core core
bt full
#0=A0 0xffffe410 in __kernel_vsyscall ()
No= symbol table available.
#1=A0 0xb7dac9a1 in ?? ()
No symbol table av= ailable.

I'm thinking that this is much shorter than it should b= e. This build was compiled with -O0 -g.

At the moment it takes about 10 minutes for the test case to run and se= gfault.

- Michael

On Thu, Mar 5, 2= 009 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 =A0-g and
=A0use 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 t= est suite
>> has a
>> > segfault at line 1413 in drb.rb. I am compiling Ruby on Ubunt= u 6.06,
>> 32bit,
>> > GCC 4.0.3. The segfault shows up when compiling at O2 and O0(= zero).
>>
>> -=3Dr
>>
>>
>
>

--
View this message in context: http://www.nabble.com/MBARI8-patch-fixes-bu= gs-caused-by-incorrect-volatile-variable-declarations-tp22259357p22357591.h= tml
Sent from the ruby-core mailing li= st archive at Nabble.com.



--00221532cf6cd3ad67046465ff5a--