Martin Husemann wrote:
> On Wed, Mar 16, 2005 at 09:38:51AM +0000, sigsegv@rambler.ru wrote:
> 
>>I'm not sure if this is sparc64 specific or gdb needs to be told to use 
>>more memory. What do you think?
> 
> 
> Unlimit your resource limits before running gdb (ulimit/limit/unlimit
> depending on your shell)
> 
> Martin
> 

Thanks, that helped. I've got 3 core dumps, generated by 3 different 
executables (all part of www/firefox package), looking at dgb output, 
they fault in one place. I think I can see what's happening here:

nanMask (or whatever it points to) is not actually a double datatype, so 
it's not aligned propery, then it's cast to (double *) and pointer is 
dereferenced, causing 'Bus error'

Should be easy to fix :-)


u10# gdb firefox-bin firefox-bin.core
<snip>
This GDB was configured as "sparc64--netbsdelf"...
Core was generated by `firefox-bin'.
Program terminated with signal 10, Bus error.
<snip>
#0  0x000000004d5386cc in __static_initialization_and_destruction_0 (
     __initialize_p=0, __priority=0) at Double.cpp:130
130     const double Double::NaN = *((double*)nanMask);


u10# gdb regchrome regchrome.core
<snip>
This GDB was configured as "sparc64--netbsdelf"...
Core was generated by `regchrome'.
Program terminated with signal 10, Bus error.
<snip>
#0  0x000000004d5386cc in __static_initialization_and_destruction_0 (
     __initialize_p=0, __priority=0) at Double.cpp:130
130     const double Double::NaN = *((double*)nanMask);
(gdb)


u10# gdb regxpcom regxpcom.core
<snip>
This GDB was configured as "sparc64--netbsdelf"...
Core was generated by `regxpcom'.
Program terminated with signal 10, Bus error.
<snip>
#0  0x000000004d5386cc in __static_initialization_and_destruction_0 (
     __initialize_p=0, __priority=0) at Double.cpp:130
130     const double Double::NaN = *((double*)nanMask);
(gdb)