Date: Mon, 10 Apr 2006 11:45:20 +1000 From: odela01 <odela01@ca.com> To: <freebsd-java@freebsd.org> Subject: Re: Diablo 1.5 SIGBUS - fixed Message-ID: <C05FF5D0.246B%odela01@ca.com> In-Reply-To: <200604071646.54787.kurt@intricatesoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Kurt Miller <kurt@intricatesoftware.com> > Date: Fri, 07 Apr 2006 16:46:54 -0400 > To: <freebsd-java@freebsd.org> > Subject: Re: Diablo 1.5 SIGBUS > > 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? I think you nailed it! Previously it would always sigbus a few seconds after launching TestNG, but after adding that argument, it completed the whole test suite, which takes about 20 minutes. Google didn't have much to say about UseMembar, can you tell me what effect it has? -- Lachlan O'Dea CA Senior Software Engineer tel: +61 3 8416 5627 fax: +61 3 8416 5810 mobile: +61 412 390 650 odela01@ca.com Relax and enjoy your shoes! > > Thanks, > -Kurt > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C05FF5D0.246B%odela01>