Bug 1023744
Summary: | xfig crashes when creating lines with linestyle 4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Maurizio Paolini <paolini> |
Component: | xfig | Assignee: | Hans de Goede <hdegoede> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | astra, hdegoede, lnie, msrb, pertusus, sochotni |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | xfig-3.2.5-41.c.fc20 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-01-14 08:36:56 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Maurizio Paolini
2013-10-27 15:14:03 UTC
Actually dash-dot is linestyle 3 (the one causing the problem), not 4. There is an apparent out-of-bounds error in a piece of code from w_drawprim.c (line 1373 and following): for (il =0; il<nd; il ++) { if (fl[il] != 0.) { if (fl[il] * style_val * display_zoomscale > 255.0) dash_list[op][il] = (char) 255; /* too large for X! */ else dash_list[op][il] = (char) round(fl[il] * style_val * display_zoomscale); } else { dash_list[op][il] = (char)display_zoomscale; } if (dash_list[op][il]==0) /* take care for rounding to zero ! */ dash_list[op][il]=1; } In the test case we have nd=4 so that il can be as large as 2 and 3, whereas matrix dash_list is apparently declared as "static unsigned dash_list[16][2]" I do not know how to fix this. Hi, Thanks for the bug report and the initial investigation of the bug. I've put this on my todo list, no promises when exactly I'll get around to fixing it, but I'll try to make some time for this sometime during the next couple of weeks. Regards, Hans (In reply to Hans de Goede from comment #2) A quick workaround would be to change the declared dimension of dash_list from dash_list[16][2] to dash_list[16][8]: =========================================================================== --- xfig.3.2.5b/w_drawprim.c.linestyle 2013-10-29 08:02:47.447300424 +0100 +++ xfig.3.2.5b/w_drawprim.c 2013-10-29 08:05:19.933394086 +0100 @@ -1265,7 +1265,7 @@ } -static unsigned char dash_list[16][2] = {{255, 255}, {255, 255}, +static unsigned char dash_list[16][8] = {{255, 255}, {255, 255}, {255, 255}, {255, 255}, {255, 255}, {255, 255}, {255, 255}, {255, 255}, =========================================================================== and I also prepared a revised rpm package for my personal use. However it is not clear to me how dash_list should be initialized (or if it actually needs to be initialized at all). > Hi, > > Thanks for the bug report and the initial investigation of the bug. I've put > this on my todo list, no promises when exactly I'll get around to fixing it, > but I'll try to make some time for this sometime during the next couple of > weeks. > > Regards, > > Hans (In reply to Maurizio Paolini from comment #3) > A quick workaround would be to change the declared dimension of dash_list > from dash_list[16][2] to dash_list[16][8]: > > =========================================================================== > --- xfig.3.2.5b/w_drawprim.c.linestyle 2013-10-29 08:02:47.447300424 +0100 > +++ xfig.3.2.5b/w_drawprim.c 2013-10-29 08:05:19.933394086 +0100 > @@ -1265,7 +1265,7 @@ > } > > > -static unsigned char dash_list[16][2] = {{255, 255}, {255, 255}, > +static unsigned char dash_list[16][8] = {{255, 255}, {255, 255}, > {255, 255}, {255, 255}, > {255, 255}, {255, 255}, > {255, 255}, {255, 255}, > =========================================================================== > > and I also prepared a revised rpm package for my personal use. However > it is not clear to me how dash_list should be initialized (or if it actually > needs to be initialized at all). As I didn't see the reported bug I did search the bug myself and (also) created a custom rpm. If anyone else has this bug and *did* look for reported bugs - my Package with exactly that fix and also bumped to the next version (3.2.5c) can be found on copr: http://copr-be.cloud.fedoraproject.org/results/astra/xfig/ (f18,f19,f20) the srpm is found on my server: http://ionic.at/xfig-3.2.5-38.c.fc19.src.rpm Best regards, David After upgrading to the latest Fedora 20, the bug is still there. Any news? Thanks Maurizio and David. I've applied David's patch. I believe it fixes this issue. David also noticed that there is a new upstream version of xfig (3.2.5c). I've opened separate bug for it (#1048127). Thanks guys and sorry for the delay. Update for F19 and F20 will follow. Hi all, Indeed thanks Maurizio and David for the input and patches. And Michal thanks for taking care of this, I've had it on my todo list for a while now but other stuff got in the way. Do you plan to also take care of the 3.2.5c update? I think it would make sense to push 3.2.5.c for F20+, and let F-19 stay at the old version so that "conservative" Fedora users keep the old version for now. David send me a patch for updating to 3.2.5c by private mail I'll attach that to the bug you've filed. Regards, Hans Yup, I will take care of 3.2.5c update for F20+ ;) xfig-3.2.5-38.b.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xfig-3.2.5-38.b.fc20 xfig-3.2.5-38.b.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xfig-3.2.5-38.b.fc19 Package xfig-3.2.5-38.b.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xfig-3.2.5-38.b.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0153/xfig-3.2.5-38.b.fc20 then log in and leave karma (feedback). xfig-3.2.5-41.c.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xfig-3.2.5-41.c.fc20 xfig-3.2.5-37.b.fc20 crash when I simply draw a circle, crash is gone in 3.2.5-41.c.fc20 what is the line style? (In reply to lnie from comment #14) > xfig-3.2.5-37.b.fc20 crash when I simply draw a circle, > crash is gone in 3.2.5-41.c.fc20 the default one:style 1 How strange... I am not able to reproduce the problem. I just tried with $ rpm -qa | grep xfig xfig-common-3.2.5-37.b.fc20.i686 xfig-3.2.5-37.b.fc20.i686 $ xfig and I do not experience the crash that you report. I do see it if I use the fourth ("line-dot") line style, but not with the default line style. All other parameters are at their default value. I have an "i686" architecture (32 bit) (In reply to lnie from comment #16) > the default one:style 1 xfig-3.2.5-38.b.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. xfig-3.2.5-41.c.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |