Bug 184245 – highlight crashes on x86_64

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 184245 - highlight crashes on x86_64

Summary:	highlight crashes on x86_64

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	highlight (Show other bugs)
Sub Component:
Version:	4
Hardware:	x86_64 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jochen Schmitt
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2006-03-07 12:40 EST by Eric Hopper
Modified:	2007-11-30 17:11 EST (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2006-03-15 11:43:51 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
This SRPM includes a patch that fixes the problem: highlight-2.4.4-2.src.rpm (336.73 KB, application/octet-stream) 2006-03-14 20:54 EST, Eric Hopper	no flags	Details
The new .spec file that was used to build the attached SRPM. (2.67 KB, text/plain) 2006-03-14 20:56 EST, Eric Hopper	no flags	Details
This patch fixes the problem (i.e. highlight-2.4-fixcodegen.patch). (620 bytes, patch) 2006-03-14 21:00 EST, Eric Hopper	no flags	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Eric Hopper 2006-03-07 12:40:13 EST

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 ?? ()

Comment 1 Jochen Schmitt 2006-03-12 15:11:50 EST

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.

Comment 2 Eric Hopper 2006-03-14 09:55:10 EST

So far, I get a problem that looks almost exactly identical in behavior.  Not
sure if it's the same stack trace yet though.

Comment 3 Eric Hopper 2006-03-14 09:58:03 EST

Still basically the same trace.  Addresses of things are a bit different is all.

Comment 4 Jochen Schmitt 2006-03-14 13:05:55 EST

I have forwarded the bug to the upstream author.

Comment 5 Eric Hopper 2006-03-14 20:54:33 EST

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.

Comment 6 Eric Hopper 2006-03-14 20:56:18 EST

Created attachment 126138 [details]
The new .spec file that was used to build the attached SRPM.

Here is the .spec file I used.

Comment 7 Eric Hopper 2006-03-14 21:00:58 EST

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.

Comment 8 Jochen Schmitt 2006-03-15 11:43:51 EST

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.

Comment 9 Eric Hopper 2006-03-16 09:42:49 EST

It works.  It would've been nice to have my name in the changelog entry, but
that's OK.  :-)  Thanks.

Note You need to log in before you can comment on or make changes to this bug.