#30 xchm crashes with signal 11 (SIGSEGV)

closed-fixed
CHM access (5)
5
2011-05-06
2011-05-04
manuel wolfshant
No

While trying to open the chm file available at http://www.springframework.net/doc-latest/reference/htmlhelp/spring-net-reference.chm, xchm crashes.
The problem was initially reported at https://bugzilla.redhat.com/show_bug.cgi?id=701827 but can be reproduced always at least in F14 and Scientific Linux 6 ( a clone of RHEL 6), even when using xchm-1.19-1
Test rpm builds are available at http://koji.fedoraproject.org/koji/taskinfo?taskID=3048888 ( for Fedora 14) and http://koji.fedoraproject.org/koji/taskinfo?taskID=3048897 ( for RHEL 6 )

Discussion

<< < 1 2 (Page 2 of 2)
  • I have compiled xchm using:
    + export 'CFLAGS=-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
    + CFLAGS='-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
    + CFLAGS='-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
    + export CFLAGS
    + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
    + export CXXFLAGS
    + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib64/gfortran/modules'
    + export FFLAGS
    + ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-debug

    I haven't found the magic button to upload attachments here in SF, so the build log and backtrace are available at http://wdl.lug.ro/linux/rpms/xchm/

     
    • status: closed-works-for-me --> open
     
  • Backtrace

     
    Attachments
  • Debug build log

     
    Attachments
  • I've uploaded the backtrace and build log here. You just need to click on "Attached files" and it expands to a list of already attached files + an "Add a file" link (at least that's how it worked for me, it's possible that SourceForge gives us different levels of access).

    Please patch the standard chmfile.cpp in your src/ directory with the new patch chmfile_verbose.diff attached here. This will output to stdout what the application is doing when parsing the binary table of contents of a CHM file (that is, the portion that doesn't work). Then run "./xchm 1> out" and give me the "out" file, so we can see what input exactly __strlen_sse() chokes on.

    I'm assuming that the application does not crash with that code commented out? Although it won't load the table of contents either.

     
  • Verbose output about loading the binary table of contents (will write to stdout)

     
    Attachments
  • output before xchm crashes when the "verbose" patch is applied

     
    Attachments
    out
  • The application no longer crashes when the section of code dealing with toc is commented ( the section you have mentioned, toBuild->Freeze() ....... return true )
    I have uploaded here the output from stdout after the "verbose" patch was applied ( and xchm crashes)

     
  • Thank you, this should be very helpful. I'll start debugging here to get to that point in the code, then I'll de-compile the CHM file to check the raw data there, then I'll let you know.

     
  • Let me know if there is any other help that I can provide. You can also reach me as wolfy in freenode and in irc.lug.ro/#mumu

     
  • Well, this is what's being read in the string, the data that supposedly chokes __strlen_sse2():

    (gdb) x/70cb (char *)(strings.get() + offset)
    0x85999e4: 67 'C' 111 'o' 109 'm' 112 'p' 97 'a' 114 'r' 105 'i' 115 's'
    0x85999ec: 111 'o' 110 'n' 32 ' ' 119 'w' 105 'i' 116 't' 104 'h' 32 ' '
    0x85999f4: 117 'u' 115 's' 105 'i' 110 'n' 103 'g' 32 ' ' 87 'W' 67 'C'
    0x85999fc: 70 'F' 0 '\000' 73 'I' 110 'n' 116 't' 114 'r' 111 'o' 100 'd'
    0x8599a04: 117 'u' 99 'c' 116 't' 105 'i' 111 'o' 110 'n' 0 '\000' 85 'U'
    0x8599a0c: 115 's' 105 'i' 110 'n' 103 'g' 32 ' ' 116 't' 104 'h' 101 'e'
    0x8599a14: 32 ' ' 81 'Q' 117 'u' 97 'a' 114 'r' 116 't' 122 'z' 46 '.'
    0x8599a1c: 78 'N' 69 'E' 84 'T' 32 ' ' 83 'S' 99 'c' 104 'h' 101 'e'
    0x8599a24: 100 'd' 117 'u' 108 'l' 101 'e' 114 'r' 0 '\000'
    (gdb)

    My suspicion was that it wouldn't be NULL terminated, but it is. So at this point I don't quite know what to do except debug on a system similar to yours. I've contacted you on IRC but you're probably away.

     
  • Whenever you have the time, please get in touch with me (on IRC), I might have an idea.

     
  • Fixed. I've attached a patch (the file called fix_64bit_bug.diff) that fixes xchm-1.19. I've also commited the fix to CVS.
    If you'd like, you can patch 1.19 and have it working right now, otherwise I think this bug warrants an early 1.20 release, so that should be available for download at the very latest tomorrow.

     
    • status: open --> closed-fixed
     
  • Bugfix patch.

     
    Attachments
<< < 1 2 (Page 2 of 2)