Diablo 1.5 SIGBUS

[Kurt Miller]

On Friday 07 April 2006 11:28 am, Dan Nelson wrote:
> In the last episode (Apr 07), Kurt Miller said:
> > On Thursday 06 April 2006 11:41 pm, Daniel Eischen wrote:
> > > On Thu, 6 Apr 2006, Kurt Miller wrote:
> > > > On Thursday 06 April 2006 8:49 pm, odela01 wrote:
> > > > > I applied the patch and did "make all install" in
> > > > > /usr/src/lib/libpthread, but it didn't make any difference.
> > > > > I'll try to arrange access to the core dump.
> > > >
> > > > Thanks for making the core dump available to me. It was helpful.
> > > > I got a partial stack trace from it:
> > > >
> > > > #0  0x280aa41b in pthread_setcancelstate () from /usr/lib/libpthread.so.2
> > > > #1  0x280a29a6 in pthread_mutexattr_init () from /usr/lib/libpthread.so.2
> > > > #2  0x00000000 in ?? ()
> > > >
> > > > This bt also supports Dan Nelson's observations that this could
> > > > be a threading issue. It would be great if you or Dan built a
> > > > debug pthreads by commenting the CFLAGS+= -g line in
> > > > /usr/src/lib/pthreads/Makefile and rebuilding/reinstall pthreads.
> > > > The back-trace from the core file would contain line numbers and
> > > > be more useful then.
> > > 
> > > That stack trace doesn't help.  pthread_mutexattr_init(), doesn't
> > > call pthread_setcancelstate().
> > > 
> > > Is there any fork()ing going on?
> > 
> > One of the reports indicated RabbIT3
> > (http://www.khelekore.org/rabbit/) was causing failures. It doesn't
> > do any fork()ing.
> 
> To keep someone else from mentioning it:  It can fork if you enable the
> image compressor, but I don't, so in my case it isn't.
> 

Hi,

I was able to catch the SIGBUS in gdb once so far on a remote
multiprocessor system. There was some evidence that the use of
of the jvm argument -XX:+UseMembar will help correct the problem.
I wasn't readily able to reproduce the problem so I'm not sure
yet if this is the proper solution. Can those of you who are
getting the SIGBUS try this and see if it improves things?

Thanks,
-Kurt