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 skipjack 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.
Created attachment 54984 [details] diff -u xdvik-22.15-j1.04.patch.orig xdvik-22.15-j1.04.patch
To be explicit about it: does this patch fix the core dump, or is it an extra fix? Thanks for the patch.
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. :)
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.
Created attachment 55204 [details] diff -u patch to SOURCES/xdvik-22.15/texk/xdvik/dvi-init.c
Created attachment 55205 [details] diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
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 it.
Created attachment 55324 [details] diff -u patch to SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
Fix applied in tetex-1.0.7-50. Thanks.
Any chance of a bugfix errata? Thanks!
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 ()
I can confirm the reread bug, but it is different from the previous bug described here. Perhaps I can try to track it down.
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).
Created attachment 63267 [details] diff -u from SOURCES/xdvik-22.15-j1.04.patch.gz (after uncompressing)
Patch applied in 1.0.7-53.