Description of problem: I start editing the circle in the file below, fill it with black color. Everything goes OK this far. Then I try to edit the fill level from 100% to 10% by deleting the final zero. The program dies immediately. Version-Release number of selected component (if applicable): xfig-3.2.4-17.3.fc5 How reproducible: Repeats always. Steps to Reproduce: 1. Open the file below in xfig. 2. Fill the circle with black 3. Try to edit the fill level by keyboard (delete the final 0). Actual results: Crashes. Expected results: Successful edit to number 10. Additional info: Output during run: Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion Warning: Missing charsets in String to FontSet conversion xfig3.2.4: SIGSEGV signal trapped xfig: figure empty or not modified - exiting
Created attachment 133909 [details] xfig .fix file with one circle.
I tried to reproduce, but it didn't crash (xfig-3.2.4-21.1). I attach the file I obtained, could youplease verify that I tested te right thing?
Created attachment 139085 [details] resullt after editing the circle (fill and set fill level to 10%)
(In reply to comment #3) > Created an attachment (id=139085) [edit] > resullt after editing the circle (fill and set fill level to 10%) Looks very similar to my SAVE.fig after the crash. I don't understand the significance of all the numbers, though. I'm not even sure that the edits get visible in the file - only the results. Are you testing this on a 64-bit system? My work computer (HP nx6325) runs the 64-bit (AMD) fc5 and the crash repeats systematically. My home computer (self-assembled) runs the 32-bit x86 Linux and does not crash. Both have the xfig-3.2.4-17.3.fc5 version. I'm sorry and puzzled if this problem is not reproduceable: I'm afraid that I cannot do much more beyond reporting. Please note that I can use the arrow up and arrow down buttons in the edit mode to successfully adjust the filling percentage. It is only the direct edit (delete final zero) from the keyboard that causes the crash.
I guess the file only shows the results. I have a 32 bit computer, so it may be a 64 bit issue. I did a direct edit, but as you said it cannot be reproduced on a 32 bit computer. To know if it is reproduceable it should be retested on a 64 bit computer.
Yes this is definetly a 64 bit bug I can reproduce it on my 64 bit system too, I'll take a look to see if I can fix it (as time permits).
Hmm, funny. The current xfig rpms in development/rawhide cannot be debugged because they have a useless -debuginfo package. I've fixed this by changing: make XFIGDOCDIR=%{_docdir}/%{name}-%{version} into: make XFIGDOCDIR=%{_docdir}/%{name}-%{version} \ CDEBUGFLAGS="$RPM_OPT_FLAGS -fno-strength-reduce -fno-strict-aliasing" And then rebuilding, notice that the "-fno-strength-reduce -fno-strict-aliasing" come from the original CFLAGS and I've kept them to be safe. After rebuilding this way I not only got a good debuginfo package, but the problem is gone too. So it looks like rebuilding with "$RPM_OPT_FLAGS -fno-strength-reduce -fno-strict-aliasing" fixes this. Don't ask why though :)
it seems an compiler issue here. Built with -O0(1) seems to workaround the problem.
the crash happens in XtCallCallbacks from libXt
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
I'm sorry, but the computer with the 64 bit OS suffered from slight BIOS-ACPI problems since the beginning, and had to be replaced altogether after the latest BIOS & OS update some weeks ago. Since the computer was not my own but my university's, I could not keep it for further testing, and I received a different computer instead. Regrettably, I am therefore not able to provide the requested information. Anyway, I want to express my warm thanks to you for working on this bug.
(In reply to comment #10) > Thanks for the bug report. We have reviewed the information you have provided > above, and there is some additional information we require that will be helpful > in our diagnosis of this issue. > > Please attach your X server config file (/etc/X11/xorg.conf) and X server log > file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file > attachments using the bugzilla file attachment link below. > > Could you please also try to run without any /etc/X11/xorg.conf whatsoever and > let X11 autodetect your display and video card? Attach to this bug > /var/log/Xorg.0.log from this attempt as well, please. > > We will review this issue again once you've had a chance to attach this information. > > Thanks in advance. Erm, how is this relevant for this bug? Both Than and I have already explained and proofed by reproducing this that this is a compiler bug, triggered by the unusual CFLAGS used during the build of xfig, using standard RPM_OPT_FLAGS, fixes this bug and as a bonus also leads to a usuable debuginfo package. See comment #7 for howto invoke make to fix this.
WTF was this closed as invalid info, this _really_ pisses me off. The reporter took the time to explain in detail how to reproduce, I took the time to reproduce and come up with a fix, yet this is still broken in rawhide and F-7 GRRRRR! I don't know who closed this as insufficient info, but that was completely ridiculous I've explained howto fix this in comment 7 and explained in comment 12 that the requested info was completely irrelevant. Reopening, reassigning to Than who is the xfig owner, changing component back to xfig. Than, Currently: -xfig doesn't honor RPM_OPT_FLAGS -doesn't have a usable debuginfo -crashes on 64 bit as explained here Changing the make line in %build from: make XFIGDOCDIR=%{_docdir}/%{name}-%{version} into: make XFIGDOCDIR=%{_docdir}/%{name}-%{version} \ CDEBUGFLAGS="$RPM_OPT_FLAGS -fno-strength-reduce -fno-strict-aliasing" Fixes all 3 of these! While you are at please also fix the License tag according to the new guidelines. Or add me to the ACL and I'll do this all for you.
Than, I understand that xfig is a low priority package, still it would be nice to get this bug and a slew of other bugs open against it fixed, so I'm offering myself as co-maintainer, or if you want even as owner. I'll be requesting the necessary rights in the packagedb in the next couple of minutes.
Than, A reply, any reply to this bug and my request for co-maintainership would be nice. Consider this my third contact attempt in the light of the AWOL maintainer procedure: http://fedoraproject.org/wiki/PackageMaintainers/Policy/AWOL_Maintainers
Hans, it's great to have you as co-maintainer. Could you please request for the xfig co-maintainer, so i can approve it? Thanks
Done, please goto: https://admin.fedoraproject.org/pkgdb/packages/name/xfig Login, and approve, Thanks!
it's now fixed in rawhide, thanks.
xfig-3.2.5-5.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xfig'
xfig-3.2.5-5.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xfig'
xfig-3.2.5-5.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
xfig-3.2.5-5.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.