Version: v0.90.0 (using 3.5.5, Debian Package 4:3.5.5a.dfsg.1-5 (4.0)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.19 The steps I have used to define my macro to plot mid point in a segment are: - plot the segment with the kig function (the points are A and B); - plot a CIRCLE with POINT & RADIUS centered in A with radius AB - plot a CIRCLE with POINT & RADIUS centered in B with radius AB - intersect cirles (result: two points C and D) - plot a line by C and D (line named r) - intersect line r with the segment and find mid point M - define a new macro that starts whith the segment and ends with M - crash...
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.