DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

linux-sun-jdk1.4.2 breakage


From: "David P. Reese, Jr." <daver@xxxxxxxxxxxx>
Date: Sat, 15 Nov 2003 18:10:35 -0800

As was pointed out a while ago, linux-sun-jdk1.4.2 is broken.  I have
built a kernel from the day before the last changes to linux_signal.c
and the day after.  Both kernels have no problem running the java binary.

I just commited a bugfix to linux_signal.c that I hoped would aleviate the
problem, but I had no such luck.

When running `java -version`, a SIGSEGV is sent to java immediately after
a call to close().  The ktrace looks like:

 64815 java     CALL  dup2(0xbfbfbf90)
 64815 java     RET   dup2 677638144/0x2863f000
 64815 java     CALL  dup2(0xbfbfbf90)
 64815 java     RET   dup2 677670912/0x28647000
 64815 java     CALL  close(0x3)
 64815 java     RET   close 0
 64815 java     PSIG  SIGSEGV caught handler=0x2806f9ac mask=0x80000000 code=0x0
 64815 java     CALL  pwrite(0xb,0xbfbfca4c,0xbfbfc9bc,0x8)
 64815 java     RET   pwrite 0

Because kdump doesn't translate the syscall names for emulated programs,
the calls to dup2() are really linux_mmap() and the call to pwrite() is
really linux_rt_sigaction().  The ktrace/kdump tools don't trace sendsig()
and sigreturn(), so it took a while to figure out that the process is hung
in the signal handler.

The solution is to figure out what is making java segfault.  Tomorrow I
should have some time to try a binary search between Oct 25 and today.

-- 
   David P. Reese, Jr.                                     daver@xxxxxxxxxxxx
                                               http://www.gomerbud.com/daver/



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]