| Summary: | define a macro to plot mid points | ||
|---|---|---|---|
| Product: | [Applications] kig | Reporter: | Emanuela <emanuelazani> |
| Component: | general | Assignee: | Pino Toscano <pino> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | cfeck, maurizio.paolini |
| Priority: | NOR | Keywords: | triaged |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | proposal of patch for this bug | ||
|
Description
Emanuela
2008-02-12 18:30:20 UTC
It seems that the assertion "assert( b->inherits( a ) );" fails in const ObjectImpType* lowermost( const ObjectImpType* a, const ObjectImpType* b ) In the specific case we have that a is a "lenght-object" and b is a "line" so that neither one inherits the other... In the given construction segment AB is used twice, one when constructing the circle with given radius (in which case it is treated as a "lenght-object", the other one when intersecting it with segment CD, now used as a "line"; now it would seem that "lowermost" should result with a ImpType from which both a and b are inherited. Since this is a partial ordering there is no guarantee that "lowermost" is either a or b. Is the implementation of lowermost wrong? > now it would seem that "lowermost" should result with a
> ImpType from which both a and b are inherited.
Mmh, perhaps it is the contrary, the required result should be the
most restrictive (which is more difficult to fix), in our case we
want an ImpType that is both a "lenght-object" and a "line" (i.e.
a "segment")
Created attachment 23772 [details]
proposal of patch for this bug
Comment on attachment 23772 [details]
proposal of patch for this bug
we can add a third argument to lowermost which is the actual ImpType of the
object
This crash report is at least 3 years old and there were no further comments or status updates since then. Therefore we believe that this crash is already fixed in recent KDE 4 versions or the backtrace is no longer applicable to the current KDE 4 sources. If the crash still happens with a recent KDE version (4.10.5 or 4.11), please add an updated backtrace or provide steps to reproduce. For more information, see http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports (To prevent automatic closing of this bug in the future, please set the bug status to ASSIGNED or CONFIRMED) Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! With the latest version of kig there is no crash. Of course the macro construction doesn't work as intended, assuming that the segment s was constructed as segment by given endpoints A and B. The point is that s depends on A and B and not the other way around. A correct construction must involve the creation of the two endpoints of s, to avoid confusion I would suggest to first HIDE the two points used to construct s, then - right-click on s and "construct" the first end-point, - construct the second end-point - proceed as described in the bug report. Of course now we directly have the "midpoint" construction, but this remark can be useful in similar circumstances. The bug report can be closed, however. |