|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
|
|
Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)We are observing a nondeterministic segmentation fault in the function find_in_catalogue of module sgml2pl.so. We have observed that this function has a very large stack frame and the segmentation fault happens just after a stack pointer decrease of more than 80 kB. We suspect that the stack expander gets confused and this is the reason of the segmentation fault, which may be nondeterministic due to the randomization of the begin-of-stack in Linux. Cheers, Abramo and Roberto Bagnara -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@... _______________________________________________ SWI-Prolog mailing list SWI-Prolog@... https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog |
|
|
Re: Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)On Tue, 2009-09-29 at 21:01 +0200, Roberto Bagnara wrote:
> We are observing a nondeterministic segmentation fault in the function > find_in_catalogue of module sgml2pl.so. > > We have observed that this function has a very large stack frame > and the segmentation fault happens just after a stack pointer > decrease of more than 80 kB. > > We suspect that the stack expander gets confused and this is > the reason of the segmentation fault, which may be nondeterministic > due to the randomization of the begin-of-stack in Linux. Try to compile with -g and get line-number and further info about the crash. Recent changes in 5.7.x fix at least two concurrency issues in error-recovery of the parser, but this seems unrelated. Cheers --- Jan _______________________________________________ SWI-Prolog mailing list SWI-Prolog@... https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog |
|
|
Re: Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)Jan Wielemaker wrote:
> On Tue, 2009-09-29 at 21:01 +0200, Roberto Bagnara wrote: >> We are observing a nondeterministic segmentation fault in the function >> find_in_catalogue of module sgml2pl.so. >> >> We have observed that this function has a very large stack frame >> and the segmentation fault happens just after a stack pointer >> decrease of more than 80 kB. >> >> We suspect that the stack expander gets confused and this is >> the reason of the segmentation fault, which may be nondeterministic >> due to the randomization of the begin-of-stack in Linux. > > Try to compile with -g and get line-number and further info about the > crash. Recent changes in 5.7.x fix at least two concurrency issues > in error-recovery of the parser, but this seems unrelated. Hi Jan, I have done what you suggested. Here are the results: Program terminated with signal 11, Segmentation fault. [New process 30680] #0 find_in_catalogue (kind=3, name=0x1c05cc0, pubid=0x0, sysid=0x0, ci=1) at catalog.c:548 548 { ichar penname[FILENAME_MAX]; (gdb) frame 0 #0 find_in_catalogue (kind=3, name=0x1c05cc0, pubid=0x0, sysid=0x0, ci=1) at catalog.c:548 548 { ichar penname[FILENAME_MAX]; Current language: auto; currently c (gdb) list 543 544 ichar const * 545 find_in_catalogue(int kind, 546 ichar const *name, 547 ichar const *pubid, ichar const *sysid, int ci) 548 { ichar penname[FILENAME_MAX]; 549 const size_t penlen = sizeof(penname)/sizeof(ichar); 550 catalogue_item_ptr item; 551 ichar const *result; 552 catalog_file *catfile; (gdb) x/i $pc 0x7fffacc9eed9 <find_in_catalogue+25>: mov %rsi,0x20(%rsp) (gdb) And here is the assembly code for find_in_catalogue: 0000000000010ec0 <find_in_catalogue>: 10ec0: 41 57 push %r15 10ec2: 31 c0 xor %eax,%eax 10ec4: 41 89 ff mov %edi,%r15d 10ec7: 41 56 push %r14 10ec9: 41 55 push %r13 10ecb: 41 54 push %r12 10ecd: 49 89 cc mov %rcx,%r12 10ed0: 55 push %rbp 10ed1: 53 push %rbx 10ed2: 48 81 ec 48 40 01 00 sub $0x14048,%rsp (1) 10ed9: 48 89 74 24 20 mov %rsi,0x20(%rsp) (2) As you can see, the stack is extended of 81992 bytes (hex 14048) in instruction (1). At the subsequent instruction (2), i.e., at the first access via the stack pointer, we have the segmentation fault. I wonder if something is not working in the automatic stack extension mechanism. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@... _______________________________________________ SWI-Prolog mailing list SWI-Prolog@... https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog |
|
|
|
|
|
Re: Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)Hello,
The following links may be useful: http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd153ed513d25bf2cae http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1294.html http://search.luky.org/linux-kernel.2005/msg10700.html Maybe you should also try with a different kernel. -- Nicolas _______________________________________________ SWI-Prolog mailing list SWI-Prolog@... https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog |
|
|
Re: Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)Nicolas Pelletier wrote:
> Hello, > > The following links may be useful: > > http://kernelnewbies.org/Linux_2_6_25#head-fc71477174376b69ac7c3cd153ed513d25bf2cae > http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1294.html > http://search.luky.org/linux-kernel.2005/msg10700.html > > Maybe you should also try with a different kernel. Hi Nicolas. Yes, yesterday Abramo was able to prove the problem is due to a bug in the Linux kernel using the attached program. Please note that this is on-topic for SWI-Prolog/Linux users because the sgml package (and possibly others) easily triggers the bug. In order to detect whether your system is vulnerable, you can do the following: $ gcc -O2 -o detect_kernel_bug detect_kernel_bug.c $ while : ; do ./detect_kernel_bug 1000 1000 || break ; done 82516 Segmentation fault $ while : ; do ./detect_kernel_bug 1000 1000 || break ; done 79892 Segmentation fault $ while : ; do ./detect_kernel_bug 1000 1000 || break ; done 81428 Segmentation fault $ while : ; do ./detect_kernel_bug 1000 1000 || break ; done 80628 Segmentation fault If your system is immune, the while will loop until you hit control-C. Otherwise it will print the distance between the end of the mmapped memory area and the beginning of the memory area allocated by the program and the address of argc, which approximately corresponds to the stack pointer value just before the allocation performed by the program. Luckily, the bug has been fixed in the Linux kernel on September 8th, 2009: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=80938332d8cf652f6b16e0788cf0ca136befe0b5 It may take some time, though, before the fix is propagated. Meanwhile, a workaround is to disable randomization of the virtual address space using setarch. Cheers, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@... #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/mman.h> #include <assert.h> #include <stdio.h> #include <stdlib.h> // Run it with ./a.out mmap_MB alloca_KB [verbose] int main(int argc, char **argv) { size_t mmap_sz = atoi(argv[1]); size_t alloca_sz = atoi(argv[2]); mmap_sz *= 1024 * 1024; alloca_sz *= 1024; int fd = open("/dev/zero", O_RDONLY); assert(fd >= 0); char* mmapped = mmap(0, mmap_sz, PROT_NONE, MAP_ANON|MAP_PRIVATE|MAP_NORESERVE, fd, 0L); assert(mmapped != 0); long d = (char*)&argc - (mmapped+mmap_sz); if (argc > 3 || (d >= 0 && d < (long)alloca_sz)) { printf("%ld\n", d); fflush(stdout); } char* stacked = __builtin_alloca(alloca_sz); *stacked = 0; return 0; } |
|
|
Re: Nondeterministic segmentation fault in find_in_catalogue (sgml2pl.so)On Friday 02 October 2009 10:07:16 am Roberto Bagnara wrote:
> while : ; do ./detect_kernel_bug 1000 1000 || break ; done Thanks. My machine is also subject :-) I propose to ignore it in general. Typically, I'd expect this to be fixed in 1 or 2 months. If you have problems with it, decrease FILENAME_MAX as a work-around. --- Jan _______________________________________________ SWI-Prolog mailing list SWI-Prolog@... https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog |
| Free embeddable forum powered by Nabble | Forum Help |