Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 63996 - xdvi and pxdvi core dump in some circumstances
xdvi and pxdvi core dump in some circumstances
Product: Red Hat Linux
Classification: Retired
Component: tetex (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-04-23 12:08 EDT by John Franks
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-12 11:39:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diff -u xdvik-22.15-j1.04.patch.orig xdvik-22.15-j1.04.patch (391 bytes, patch)
2002-04-23 12:12 EDT, John Franks
no flags Details | Diff
diff -u patch to SOURCES/xdvik-22.15/texk/xdvik/dvi-init.c (794 bytes, patch)
2002-04-24 12:01 EDT, John Franks
no flags Details | Diff
diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing) (534 bytes, patch)
2002-04-24 12:04 EDT, John Franks
no flags Details | Diff
diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing) (523 bytes, patch)
2002-04-25 13:59 EDT, John Franks
no flags Details | Diff
diff -u from SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing) (660 bytes, patch)
2002-07-01 13:48 EDT, John Franks
no flags Details | Diff

  None (edit)
Description John Franks 2002-04-23 12:08:41 EDT
Description of Problem:
When using xdvi or pxdvi if an attempt is made to create a new dvi file
with latex or tex and it fails due to an error in the tex source then
xdvi or pxdvi often core dumps.

Version-Release number of selected component (if applicable):
All versions using xdvik-22.15-j1.04.patch.gz.  This includes RH 7.2 and

How Reproducible:
It varies with the tex source file.  Once you produce it, it can be reliably
reproduced by repeating steps.

Steps to Reproduce:
1. Create large latex file a.tex; run latex producing a.dvi
2. Run xdvi a.dvi, leave running; edit a.tex creating an error in the middle;
   rerun latex.
3. When "corrupted dvi file" message occurs in xdvi, exit latex with ctrl-C.
   Give focus to xdvi.  It core dumps.

Actual Results: Core dump.

Expected Results: No core dump.

Additional Information:
There is a bug in xdvik-22.15-j1.04.patch.gz in the source.  It is an off by
one error causing the freeing of pointer off the end of an array of

     for (i = 0; i <= total_pages; i++)
should be 
     for (i = 0; i < total_pages; i++)
I will attach a patch.  It is a patch to a patch.  gunzip
xdvik-22.15-j1.04.patch.gz, apply patch or hand edit and re-gzip.
Comment 1 John Franks 2002-04-23 12:12:22 EDT
Created attachment 54984 [details]
diff -u xdvik-22.15-j1.04.patch.orig xdvik-22.15-j1.04.patch
Comment 2 Tim Waugh 2002-04-23 12:13:47 EDT
To be explicit about it: does this patch fix the core dump, or is it an extra 
Thanks for the patch.
Comment 3 John Franks 2002-04-23 13:28:58 EDT
Sorry.  This patch fixes the core dump.  

It is a trivial fix.

This sporadic core dump has been driving me crazy for several months.  This
morning I decided I needed to do something about.  My writing is going
more smoothly now.  :)
Comment 4 John Franks 2002-04-24 11:58:16 EDT
Sigh.  Well, I am sad to say this bug is not fixed by the patch I suggested. I
have two patches which certainly seem to make the core dumps go away, but it
would be better if the problem were fixed by someone who understands the code.

Here is what is going on, I think:
From the file SOURCES/xdvik-22.15-j1.04.patch.gz uncompressed we see
#ifdef COLOR
		if (page_color) {
		    int i;
		    for (i = 0; i <= total_pages; i++)
			if (page_color[i].color_stack)
			    free((char *) page_color[i].color_stack);
		    free((char *)page_color);

Changing i <= total_pages to i < total_pages as I first suggested doesn't hurt
and may help.  But if appears that the free() in the loop is freeing the same
pointer multiple times.  This only seems to happen when the dvifile has become
corrupted due to a tex source error causing it to be only partly written when
tex or latex is run.

The "fix" which I can live with just keeps track of when this corruption has
occurred and doesn't do the free.  This trades a core dump for a small memory
leak.  The patches will be attached.

I can pretty reliably get the bug to happen as follows:
1. Get a large latex file xxx.tex (about 30 pages) and latex it producing xxx.dvi
2. Run xdvi xxx.dvi and leave it running in its window.
3. In xxx.tex towards the end insert the two characters \] on a line by
themselves, introducing an error.
4. Run latex xxx.tex it will stop reporting the error.
5. Click to raise xdvi window (shows "Corrupt dvi file")
6. Click to raise terminal window running latex. Type X or ctrl-C
7. Click to raise xdvi window -- core dump

The terminal window containing latex and the xdvi window should be overlapping.

Comment 5 John Franks 2002-04-24 12:01:35 EDT
Created attachment 55204 [details]
diff -u  patch to SOURCES/xdvik-22.15/texk/xdvik/dvi-init.c
Comment 6 John Franks 2002-04-24 12:04:18 EDT
Created attachment 55205 [details]
diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
Comment 7 John Franks 2002-04-25 13:57:32 EDT
I think I have a good fix for this now.  Apply the attached patch to 
the original SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing).
I.e. ignore my previous patches.  This one is called xdvi.patch.
Here is what this patch does

 +#ifdef COLOR
	if (page_color) {
	    int i;
	    for (i = 0; i <= total_pages; i++)
	    for (i = 0; i < total_pages; i++)
		if (page_color[i].color_stack)
		    free((char *) page_color[i].color_stack);
	    free((char *)page_color);
	    free((char *)page_color); page_color = NULL;
	if (color_allocated_top) {
	    XFreeColors(DISP, our_colormap,

The important change is the second one.  It has the following features:

1. It eliminates all core dumps I have been able to produce.
2. Unlike my previous fix there is no possibility of a new memory leak.
3. NULLing a pointer which has just been freed *should* be perfectly 
   ok.  If there is a problem afterwards there was one before.

In fact, I have had *no* problems after applying this patch.  I am about
to unleash this on my department, so if something breaks should hear about

Comment 8 John Franks 2002-04-25 13:59:47 EDT
Created attachment 55324 [details]
diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
Comment 9 Tim Waugh 2002-06-21 12:13:56 EDT
Fix applied in tetex-1.0.7-50.  Thanks.
Comment 10 Aleksey Nogin 2002-06-30 19:38:31 EDT
Any chance of a bugfix errata? Thanks!
Comment 11 Aleksey Nogin 2002-06-30 19:50:00 EDT
Unfortunatelly this problem (or at least a part of it) still seems to be there.
I've installed tetex-xdvi-1.0.7-51 from Rawhide on a 7.2 system (w/o upgrading
the rest of the tetex packaged). pxdvi still crashes, if I

1) pxdvi xyz&
2) latex xyz
3) While latex is running (but after it processes at least the first page),
press "reread" button.
4) While latex is still running, press "reread" again.

(gdb) bt
#0  0x0806c300 in get_Page_size ()
Comment 12 John Franks 2002-06-30 21:25:04 EDT
I can confirm the reread bug, but it is different from the previous bug
described here.  Perhaps I can try to track it down.
Comment 13 John Franks 2002-07-01 13:45:50 EDT
The problem is in texk/pxdvik/toc.c.  When the function set_TOC() is called by
clicking the reread button while latex is running the value of page_index is
NULL but an attempt is made to derefence it. 

I will submit a patch based on version 1.0.7-51 which seems to fix the problem.
 At least it works for me. The patch is to SOURCES/xdvik-22.15-j1.04.patch.gz
(after uncompressing).
Comment 14 John Franks 2002-07-01 13:48:03 EDT
Created attachment 63267 [details]
diff -u from SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
Comment 15 Tim Waugh 2002-07-12 11:39:39 EDT
Patch applied in 1.0.7-53.

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