Summary: | dev-tex/luatex-0.50.0 /usr/bin/luatex segfaults | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | TeX project <tex> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hppa, sparc |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 301943 | ||
Attachments: |
gdb backtrace [hppa]
build log |
Description
Jeroen Roovers (RETIRED)
2010-01-26 03:34:25 UTC
Created attachment 217436 [details]
gdb backtrace [hppa]
is that just running luatex without argument? snippet of code: pdfstructure *p; int decimal_digits = pdf->decimal_digits; assert(pdf != NULL); if (pdf->pstruct == NULL) pdf->pstruct = xmalloc(sizeof(pdfstructure)); p = pdf->pstruct; setpdffloat(p->pdf.h, 0, decimal_digits); setpdffloat(p->pdf.v, 0, decimal_digits); p->cw.e = 1; p->fs_cur.e = p->fs.e = decimal_digits + 2; it seems it segfaults on the last line. Whats the value of 'p' here? Or rather, since it doesnt seem to segfault on p->cw dereferences, why does it segfault on p->fs_cur ? What are the sizes of the 'unsigned' and 'size_t' types on hppa? xmalloc takes unsigned and gives it to malloc which takes a size_t, maybe this is the cause and not enough memory is allocated but i doubt it. What's the value of sizeof(pdfstructure) for you? Ho, and what is your texlive-core version? (In reply to comment #2) > is that just running luatex without argument? Yes. > snippet of code: > pdfstructure *p; > int decimal_digits = pdf->decimal_digits; > assert(pdf != NULL); > if (pdf->pstruct == NULL) > pdf->pstruct = xmalloc(sizeof(pdfstructure)); > p = pdf->pstruct; > setpdffloat(p->pdf.h, 0, decimal_digits); > setpdffloat(p->pdf.v, 0, decimal_digits); > p->cw.e = 1; > p->fs_cur.e = p->fs.e = decimal_digits + 2; > > > it seems it segfaults on the last line. Whats the value of 'p' here? > Or rather, since it doesnt seem to segfault on p->cw dereferences, why does it > segfault on p->fs_cur ? > > What are the sizes of the 'unsigned' and 'size_t' types on hppa? > xmalloc takes unsigned and gives it to malloc which takes a size_t, maybe this > is the cause and not enough memory is allocated but i doubt it. > What's the value of sizeof(pdfstructure) for you? I'm not an expert on the usage of gdb, but here goes: (gdb) print sizeof(pdfstructure) $1 = 216 (gdb) print sizeof(pdf) $2 = 4 (gdb) print sizeof(p) $3 = 4 (gdb) print sizeof(size_t) $4 = 4 (gdb) print sizeof(unsigned int) $5 = 4 I'll recompile without optimisation to maybe achieve better output. (In reply to comment #3) > Ho, and what is your texlive-core version? app-text/texlive-core-2008-r7 With -O0: (gdb) run Starting program: /usr/bin/luatex Program received signal SIGSEGV, Segmentation fault. 0x0005471c in init_pdf_pagecalculations (pdf=0xa75e10) at luatexdir/pdf/pdfpage.c:46 46 luatexdir/pdf/pdfpage.c: No such file or directory. in luatexdir/pdf/pdfpage.c (gdb) thread apply all bt full Thread 1 (process 16978): #0 0x0005471c in init_pdf_pagecalculations (pdf=0xa75e10) at luatexdir/pdf/pdfpage.c:46 p = 0x2710 decimal_digits = 4 __PRETTY_FUNCTION__ = "init_pdf_pagecalculations" #1 0x0004922c in init_pdf_struct (pdf=0xa75e10) at luatexdir/pdf/pdfgen.c:107 __PRETTY_FUNCTION__ = "init_pdf_struct" #2 0x0007cf8c in initialize () at luatexdir/tex/maincontrol.c:3440 k = 10832136 __PRETTY_FUNCTION__ = "initialize" #3 0x0006f340 in main_initialize () at luatexdir/tex/mainbody.c:384 bad = 0 #4 0x0006f464 in main_body () at luatexdir/tex/mainbody.c:402 No locals. #5 0x00038788 in main (ac=1, av=0xfb3b1028) at luatexdir/luatex.c:430 No locals. Created attachment 218301 [details]
build log
One thing to note is that the PARISC stack grows up, not down as most architectures have it. It doesn't look like the luatex build system checks for this, and maybe xmalloc assumes it grows down. Of course, it is also interesting that 0.30.* never had this problem. Same on sparc...maybe big-endian issues? And in my case is running 'luatex' without any argument Look at the following patch: Index: luatex-beta-0.50.0/source/texk/web2c/luatexdir/pdf/pdfgen.c =================================================================== --- luatex-beta-0.50.0.orig/source/texk/web2c/luatexdir/pdf/pdfgen.c +++ luatex-beta-0.50.0/source/texk/web2c/luatexdir/pdf/pdfgen.c @@ -24,6 +24,7 @@ static const char __svn_version[] = #include "ptexlib.h" #include <ctype.h> #include "md5.h" +#include <stdio.h> /* for tokenlist_to_cstring */ @@ -104,6 +105,7 @@ PDF init_pdf_struct(PDF pdf) init_dest_names(pdf); pdf->resources = NULL; + printf("%p\n", pdf->pstruct); init_pdf_pagecalculations(pdf); return pdf; Index: luatex-beta-0.50.0/source/texk/web2c/luatexdir/pdf/pdfpage.c =================================================================== --- luatex-beta-0.50.0.orig/source/texk/web2c/luatexdir/pdf/pdfpage.c +++ luatex-beta-0.50.0/source/texk/web2c/luatexdir/pdf/pdfpage.c @@ -37,6 +37,7 @@ static const char __svn_version[] = void init_pdf_pagecalculations(PDF pdf) { + printf("%p\n", pdf->pstruct); pdfstructure *p; int decimal_digits = pdf->decimal_digits; assert(pdf != NULL); The two printf should print the same thing. However, on bender, what I get is: # luatex (nil) 0x2710 Segmentation fault So the value changed during the init_pdf_pagecalculations call; this is really weird. Since 0x2710 != NULL, it doesn't get malloc'ed and hence the segfault. In gdb, in the function init_pdf_struct sizeof(*pdf) is 624. In function init_pdf_pagecalculations, sizeof(*pdf) is 604. So this is probably what breaks it. what is fun, if I print *pdf in these functions: from init_pdf_struct, interesting parts are: mem_size = 10000, mem = 0x99c350, mem_ptr = 1, pstruct = 0x0, posstruct = 0x93c6a8 from init_pdf_pagecalculations: mem_size = 0, mem = 0x0, mem_ptr = 0, pstruct = 0x2710, posstruct = 0x99c350 remark that mem in the first one is equal to posstruct in the second. mem_size = 10000 = 0x2710, thus the first mem_size is equal to the second pstruct. (In reply to comment #10) > In gdb, in the function init_pdf_struct sizeof(*pdf) is 624. In function > init_pdf_pagecalculations, sizeof(*pdf) is 604. So this is probably what breaks > it. On x86_64 and ppc64 those are the same. On x86 they differ. so it turned up that it was largefile support again... there was a mismatch between various headers and thus causing sizeof(off_t) mismatches between different .c files. This is fixed in -r1 |