Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#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 3 4 > >> (Page 2 of 4)
  • The flag is not --debug, it is --enable-debug. Please make sure you're using the correct flag. It should be listed if you run xCHM's ./configure --help.

     
  • I do know the difference between --debug and --enable-debug. I was just using a shortcut :)

     
  • I've just noticed that the Gentoo .ebuild file for chmlib says this:

    KEYWORDS="alpha amd64 hppa ~ia64 ppc ppc64 x86"

    The '~' character before 'ia64' means that the Gentoo chmlib maintainers don't think it quite works as it should on ia64 platforms. This may be because they haven't managed to compile it with the proper flags, or that there's some fault with the code itself.

    Not sure if this helps you or not. Maybe tinker with chmlib as well, on your platform?

     
  • Could you also paste this portion of the output from configure:

    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for int32_t... yes
    checking for int16_t... yes
    checking for uint16_t... yes
    checking for uint32_t... yes
    checking for uint64_t... yes

    or attach the config.log file to this bug report, so we can make 100% sure those types are properly matched?

     
  • checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for int32_t... yes
    checking for int16_t... yes
    checking for uint16_t... yes
    checking for uint32_t... yes
    checking for uint64_t... yes
    checking chm_lib.h usability... yes
    checking chm_lib.h presence... yes
    checking for chm_lib.h... yes
    checking for chm_open in -lchm... yes
    configure: creating ./config.status

    The whole log is available from Fedora's build system: http://koji.fedoraproject.org/koji/getfile?taskID=3048889&name=build.log

    obs: IA64 is not supported by Fedora. x86_64 on the other hand, is.

     
  • You're putting -O2 in all relevant flags before running configure:

    + CFLAGS='-O2 -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

    That forces a build with -O2 on even when --enable-optimize is not present as a configure flag. Now, I'm interested in this:

    1. Does the problem go away if -O2 is not present when compiling xCHM? If not, obtain a backtrace and proceed to step 2.

    2. Does the problem go away if you comment out the code I told you about earlier?

    Let me know.

     
  • -O2 is standard for all fedora packages.

    I'll let you know once I do the tests. I am at work now, no time for compiling and such, unfortunately
    Thank you for your support

     
  • I understand that, I'm not suggesting that you stop using -O2 in production builds. But for now, we need to narrow the possibilities that lead to the issue.

     
  • Patch for chmfile.cpp

     
    Attachments
  • Actually, before trying anything else. please patch src/chmfile.cpp using the chmfile.diff file I've attached here. To apply the patch. download the chmfile.diff file in your xchm/src/ directory, and then run "patch < chmfile.diff".

    This should, at the very least, get rid of this compiler warning from your build:

    chmfile.cpp:1120:42: warning: dereferencing type-punned pointer will break strict-aliasing rules

    and maybe it will even help fix the whole issue. So apply that patch, compile like you normally would, and if that doesn't fix things go ahead with the two steps outlined below (no -O2, chmfile.cpp code commented out).

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