Description of problem: highlight consistently crashes on my 64-bit system when formatting Python code. It may also happen with other languages. I've not tested those. I have tested a Pentium 4 box, and it worked just fine there. Version-Release number of selected component (if applicable): 2.4.3 How reproducible: Always Steps to Reproduce: 1.Find a Python file 2.Find an x86_64 system 3.highlight -X <python file> Actual results: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>__init__.py</title> <link rel="stylesheet" type="text/css" href="highlight.css"/> </head> <body class="hl"> Segmentation fault (core dumped) Expected results: A nicely formatted XHTML version of the source code. Additional info: Here's a backtrace. It's very consistent: #0 highlight::CodeGenerator::readNewLine (this=0x575550, newLine=@0x575830) at codegenerator.cpp:290 #1 0x0000000000423830 in highlight::CodeGenerator::getInputChar (this=0x575550) at codegenerator.cpp:339 #2 0x0000000000423a4a in highlight::CodeGenerator::getCurrentState ( this=0x575550, lastStateWasNumber=Variable "lastStateWasNumber" is not available. ) at codegenerator.cpp:358 #3 0x0000000000426912 in highlight::CodeGenerator::processRootState ( this=0x575550) at codegenerator.cpp:803 #4 0x00000000004259bc in highlight::CodeGenerator::generateFile ( this=0x575550, inFileName=@0x573598, outFileName=@0x7fffffede600) at codegenerator.cpp:696 #5 0x0000000000406673 in HighlightApp::run (this=0x7fffffede790, argc=Variable "argc" is not available. ) at main.cpp:414 #6 0x00000000004072b1 in main (argc=3, argv=0x7fffffede908) at main.cpp:452 #7 0x000000358cc1c3cf in __libc_start_main () from /lib64/libc.so.6 #8 0x0000000000403dd9 in _start () #9 0x00007fffffede8f8 in ?? () #10 0x0000000000000000 in ?? ()
The upstream author has released version 2.4.4 of highlight. I have create a new package which should be available in few days. Becouse I don't have a 64-bit system, It may be nice, If you can check this package.
So far, I get a problem that looks almost exactly identical in behavior. Not sure if it's the same stack trace yet though.
Still basically the same trace. Addresses of things are a bit different is all.
I have forwarded the bug to the upstream author.
Created attachment 126137 [details] This SRPM includes a patch that fixes the problem: highlight-2.4.4-2.src.rpm I've attached an SRPM that fixed this bug by patching the source slightly. I will also attach the .spec file and the patch.
Created attachment 126138 [details] The new .spec file that was used to build the attached SRPM. Here is the .spec file I used.
Created attachment 126139 [details] This patch fixes the problem (i.e. highlight-2.4-fixcodegen.patch). This is the patch referenced by the .spec file and included in the new SRPM. The read of the very first line resulted in line (since it had never had anything before) containing nothing, and lineIndex being 0. This caused a SEGFAULT on my x86_64 system as addr + 0xffffffff wasn't a valid address. But it worked fine on an x86 platform because addr - 1 (i.e. addr + 0xffffffff on a 32 bit system) IS a valid address. The fix is kind of ugly, and just special cases the previously failing case.
I have integrated the sugg. patch in the package. In the next day you may found highlight 2.4.4-2 in the repositories of FE. If the fixed didn't solve your problem, you may reopen this bug.
It works. It would've been nice to have my name in the changelog entry, but that's OK. :-) Thanks.