Latest 2.6.13-rc6-pa2 test pr :_(
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines
Quoted 7 lines
TOC:
r2
__handle_mm_fault+0x68(return from call topte_alloc_map)
IIA__handle_mm_fault+0x190It looks as if this might have been caused by Process_3.exe in the libjava GCC testsuite.
Does it always hang in the same place? How much RAM/swap do you have in your system? Does it hang more/less if you disable swap?
I've seen this fault before. I don't have enough data at this point with 2.6.13 to say it always hangs in the same place.
RAM: 1GB
SWAP:
root@hiauly6:/home/dave# cat /proc/swaps Filename Type Size Used Priority /dev/sdb1 partition 265032 0 -1 /dev/sda1 partition 263144 0 -2
dave@hiauly6:~$ ulimit -v 524288
The above limit was sufficient to prevent the as crash associated with the 1GB .block directive.
I don't know the answer to the last question at this time.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 10 lines
Quoted 7 lines
TOC:
r2
__handle_mm_fault+0x68(return from call topte_alloc_map)
IIA__handle_mm_fault+0x190It looks as if this might have been caused by Process_3.exe in the libjava GCC testsuite.
Does it always hang in the same place? How much RAM/swap do you have in your system? Does it hang more/less if you disable swap?
Had another hang last night. Here is the TOC for it:
r2 intr_check_sig+0
IIA handle_interruption+0x30
r26,r5 code = 0x1a = 26 => Data Memory Access Rights Trap
This again occurred in the libjava testsuite:
byte compile: /home/dave/gnu/gcc-4.0/objdir/gcc/gcj -B/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libjava/ -B/home/dave/gnu/gcc-4.0/objdir/gcc/ --encoding=UTF-8 -C -I/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libjava/testsuite/../libgcj-4.1.0.jar -g /home/dave/gnu/gcc-4.0/gcc/libjava/testsuite/libjava.lang/SyncTest.java -d/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libjava/testsuite 2>@ stdout
PASS: SyncTest byte compilation
SyncTestSyncTest set_ld_library_path_env_vars: ld_library_path=.:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc-4.0/objdir/gcc
Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc-4.0/objdir/gcc:.:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc-4.0/objdir/gcc:.:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/./libjava/.libs:/home/dave/gnu/gcc-4.0/objdir/gcc:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.0/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc-4.0/objdir/./gcc:/home/dave/gnu/gcc-4.0/objdir/./prev-gcc:/usr/lib/debug Exception in thread "Thread-1" Exception in thread "Thread-2" Exception in thread "Thread-3" Exception in thread "Thread-4"
I found that Process_3.exe was generating unaligned exceptions. This was a result of a new macro define being added to libjava (UNWRAP_FUNCTION_DESCRIPTOR). This macro was incorrectly doing function pointer canonicalization resulting in the unaligned exceptions. I was testing a fix for this when I got the above hang.
I have the feeling that there is at least one more circumstance where handle_exceptions can loop.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 8 lines · John David Anglin
Quoted 8 lines
Quoted 7 lines
TOC:
r2
__handle_mm_fault+0x68(return from call topte_alloc_map)
IIA__handle_mm_fault+0x190It looks as if this might have been caused by Process_3.exe in the libjava GCC testsuite.
Quoted 9 lines
Quoted 1 line
Does it always hang in the same place? How much RAM/swap do you have in your system? Does it hang more/less if you disable swap?
Had another hang last night. Here is the TOC for it:
r2 intr_check_sig+0
IIAhandle_interruption+0x30
r26,r5 code =0x1a= 26 => Data Memory Access Rights Trap
mmm, from pure user point of view that sounds a bit like a segv?
and btw in traps.c still stand some other
[...]
479 void handle_interruption(int code, struct pt_regs *regs) 480 {
[...]
737 force_sig_info(SIGSEGV, &si, current);
[...]
781 force_sig_info(SIGSEGV, &si, current);[...]
This last one is specialy interesting as (if I well understand) ending handle_interruption() for case 26.
Unfortunately, not yet find how to fix it:
o as tausq did for signal.c
o s/force_sig_info(SIGSEGV, &si, current)/force_sig(SIGSEGV, current)/
Joel
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 10 lines
737 force_sig_info(SIGSEGV, &si, current); [...] 781 force_sig_info(SIGSEGV, &si, current);[...]
This last one is specialy interesting as (if I well understand) ending
handle_interruption()for case 26.Unfortunately, not yet find how to fix it:
o as tausq did forsignal.c
o s/force_sig_info(SIGSEGV, &si, current)/force_sig(SIGSEGV, current)/
Hmmm, possibly all SIGSEGV calls to force_sig_info are potentially subject to looping. I see ia64 defines a function force_sigsegv_info. The important difference being the following bit of code:
if (sig == SIGSEGV) {
/*
* Acquiring siglock around the sa_handler-update is almost
* certainly overkill, but this isn't a
* performance-critical path and I'd rather play it safe
* here than having to debug a nasty race if and when
* something changes in kernel/signal.c that would make it
* no longer safe to modify sa_handler without holding the
* lock.
*/ spin_lock_irqsave(¤t->sighand->siglock, flags); current->sighand->action[sig - 1].sa.sa_handler = SIG_DFL; spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
where it looks as if it resets the handler for the signal to SIG_DFL. This same bit of code is in force_sigsegv. If we were to do this, I see that we need to handle SEGV_MAPERR and SI_KERNEL.
I think we may also want to reset the handler for SIGBUS.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 5 lines
I found that Process_3.exe was generating unaligned exceptions. This was a result of a new macro define being added to libjava (
UNWRAP_FUNCTION_DESCRIPTOR). This macro was incorrectly doing function pointer canonicalization resulting in the unaligned exceptions. I was testing a fix for this when I got the above hang.
Process_3.exe was causing unaligned traps, but it was not the process running when the system hung, right?
Quoted 2 lines
I have the feeling that there is at least one more circumstance where
handle_exceptionscan loop.
In this case, when the machine hung, was it the same as before, where it will still respond to sysrq and pings?
In the previous case (stack overflow), I was able to debug this further by running the hanging process in the background (i.e. ./cc1plus ... &). Now when it hangs, I was still able to use the console and run strace on it. I wonder if you ran the gcc testsuite in the background, will the machine still respond sufficiently when it is "hung" that you can do some more debugging? strace should tell you if you are having another signal loop.
randolph
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 2 lines
Process_3.exe was causing unaligned traps, but it was not the process running when the system hung, right?
I'm not sure. It was the last test run in the log but this isn't a reliable indication.
I installed a GCC fix last night which fixes Process_3.exe, so it doesn't generate the unaligned faults anymore. The fixes stack traces under java. However, there's still a problem when gij is used (PR libgcj/21692). I haven't figured out how to debug this.
Quoted 2 lines
In this case, when the machine hung, was it the same as before, where it will still respond to sysrq and pings?
I'm not sure about sysrq but the machine was still responding to pings.
Quoted 7 lines
In the previous case (stack overflow), I was able to debug this further by running the hanging process in the background (i.e. ./cc1plus ... &). Now when it hangs, I was still able to use the console and run strace on it. I wonder if you ran the gcc testsuite in the background, will the machine still respond sufficiently when it is "hung" that you can do some more debugging? strace should tell you if you are having another signal loop.
I actually run GCC builds and the testsuite in the background all the time. So, it's definitely possible to do this from the console. Problem is the machine is downtown at NRC and it's not setup with a serial console. I know from past experience that ssh connections die.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux