#30 xchm crashes with signal 11 (SIGSEGV)

CHM access (5)
manuel wolfshant

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 )


<< < 1 2 3 4 > >> (Page 3 of 4)
  • I just did a test with your patch included and a normal fedora build. There is no difference, the program still crashes.
    I'll try later to do the "remove -O2 / add debug options / remove content starting with line 434 " dance.

  • The problem still crashes but at least it now compiled without any warnings, right?

  • The build log for the patched version is available at http://wolfy.fedorapeople.org/xchm/build.log in case you want to take a look.. As you have intended, the "dereferencing type-punned pointer will break strict-aliasing rules" warning no longer exists.

  • Thanks. I'll fix the comparison warnings, but I am sure they can't possibly cause the crash so we don't need to bother with patches for that too.

    There was a very slim chance that the strict aliasing warning, combined with the -O2 flag could have produced malfunctioning binary code, but apparently that is not the case. Onwards and forwards.

  • Is there somewhere I could SSH maybe, where I could compile xCHM and debug for myself? On a Fedora x86_64 system, with X forwarding via SSH?

    If it's possible and you prefer it that way let me know, but don't post user access data here.

  • 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

  • Debug build log

  • 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.

<< < 1 2 3 4 > >> (Page 3 of 4)