View Issue Details

IDProjectCategoryView StatusLast Update
0001133FreeCADBugpublic2013-09-03 13:00
Reporterulrich1a Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version0.13 
Target VersionFixed in Version0.14 
Summary0001133: crash at padding a sketch with 42 holes
DescriptionFreeCAD crashes with "Speicherzugriffsfehler" = memory access violation? at making a pad from a sketch with 42 holes. It works flawless for 36 holes on my system.
I am using the attached python script in order to generate the part.
Additional InformationI am using freecad_0.13-git2118_i386.deb. at Debian wheezy 32 bit
TagsNo tags attached.
FreeCAD Information

Activities

2013-05-19 15:05

 

skizze.py (Attachment missing)

wmayer

2013-05-21 10:08

administrator   ~0003171

No crash here with Win7. Btw, your script creates a sketch with (7*7=) 49 holes.

normandc

2013-05-24 21:30

manager   ~0003178

No crash either on Ubuntu 12.04 LTD 64-bit and FreeCAD 0.14.2127 (version number was switched from 0.13 to 0.14 not long ago).

A more efficient way to work and potentially less problematic would be to:

1. create a sketch of the outline
2. pad it
3. create a sketch for a single hole
4. pocket it
5. create a multitransform feature of the pocket with 2 linear patterns.

2013-05-24 21:31

 

skizze-alternate.fcstd (Attachment missing)

normandc

2013-05-24 21:33

manager   ~0003179

I attached the skizze-alternate.fcstd file because I was unable to make my recorded macro working.

Jriegel

2013-06-26 13:05

administrator   ~0003253

Can not reproduce, pad works for me (Windows 0.13)

Jriegel

2013-06-26 13:06

administrator   ~0003254

Works even with 10x10 holes...

ulrich1a

2013-06-30 18:32

reporter   ~0003301

I can confirm that the Windows-Version of FreeCAD on my machine has no problems running skizze.py.
It seems to be a problem with Debian Wheezy or my installation of Debian. The segfault is in libTKernel.so.7 from oce. Unfortunatly all debugging symbols where stripped. So I have actually no more hints.

wmayer

2013-07-01 06:53

administrator   ~0003302

Do you have a chance to test the current developer version 0.14 (from git) or even compile it yourself?

Most of the crashes inside a OCC library is an indication for a bug in OCC itself which we cannot fix then. However, in 0.14 we make use of feature of OCC where we can "convert" system signals (like SIGSEGV) into C++ exceptions and handle them properly in FreeCAD so that it no longer simply crashes.

Btw, even if debug symbols are stripped out you should be able to get a stack trace which might give some more useful information.

2013-07-02 18:02

 

backtrace_segfault_skizze.py.txt (Attachment missing)

ulrich1a

2013-07-02 18:12

reporter   ~0003325

I compiled the latest version of FreeCAD from Github. I attached the backtrace.
FreeCAD aborts with
*** Abort *** an exception was raised, but no catch was found.
    ... The exception is:SIGSEGV 'segmentation violation' detected. Address 3

What version from Opencasdade is used in the Windows-Version OCC or OCE? I have compiled with OCE 0.13. The issue was also present with Debian OCE 0.9.1.

wmayer

2013-07-03 03:57

administrator   ~0003326

There are two interesting points:

1. The application still crashes even that we have set OSD::SetSignal(Standard_False) to convert a SIGSEGV to a Standard_Failure exception. No clue why this happens.

2. It crashes inside Wire_Compare where we add the shape to a bounding box to compare the diagonal length. However, somehow one of the wire is a null shape. This is checked now and hopefully works now.

Can you check again, please?

git show 14ced6b

jannekro

2013-07-03 12:07

reporter   ~0003327

No problem here either. Random 0.13 version, and latest from git.
Ubuntu 13.04.

2013-07-03 20:08

 

bt3_full_SIGSEGV_skizze.py.txt (Attachment missing)

ulrich1a

2013-07-03 20:21

reporter   ~0003329

The patch did not help. I uploaded a full backtrace.

The crash is a mystery for me. I run FreeCAD in valgrind. It gave thousends of error warnings, but skizzy.py did run without problems.

What kind of debugging could help?

wmayer

2013-07-04 04:20

administrator   ~0003330

One thing is to write out the wires so that we can analyze them on another system. Therefore you have to adjust the class SketchBased::Wire_Compare.

In its operator() method add these lines:
BRepTools::Write(w1, "/tmp/wire1.brep");
BRepTools::Write(w2, "/tmp/wire2.brep");

and you maybe have to include this header:
#include <BRepTools.hxx>

ulrich1a

2013-07-06 17:08

reporter   ~0003341

I tried your approach. FreeCAD crashes then in BRepTools::Write before exporting the wire.

I got help from an experienced programmer in the debugging session. He found the following:
Sometimes, w2 has a nullpointer in myLocation, but w2.IsNull doesn't check for that.
Instead of a nullpointer, it might need to have an "UndefinedHandleAddress",
or Wire_Compare needs to check for myLocation, too,
or whatever is generating that nullpointer needs to stop doing that.

wmayer

2013-07-07 07:03

administrator   ~0003345

What a weird behaviour. I never have seen something like this and have no clue how this can be possible. I have more the impression that there is a mixture of different OCE/OCC versions on your system.

Anyway, the TopLoc_Location class doesn't have a member to check if an instance is invalid. But what value does this return:

printf("%d\n",w1.Location().HashCode(INT_MAX));
printf("%d\n",w2.Location().HashCode(INT_MAX));

ulrich1a

2013-07-07 08:46

reporter   ~0003346

I removed the Debian packages of oce0.9.1. I removed the salome binary install from my home directory which came with occ installed in the home directory.

But FreeCAD is clearly running with the oce0.13 version in /usr/local/lib.
I added w1: and w2: to your code.
Unfortunatly the hash code is the same for all instances of the wires.
 
w2: 1776709763
w1: 1776709763
*** Abort *** an exception was raised, but no catch was found.
    ... The exception is:SIGSEGV 'segmentation violation' detected. Address c

My understanding is skizze.py generates a structure with the outermost wire in the first place. By generating the face from this structure the outermost wire has to be sorted to the last place of the structure. Somewere in the sorting the data from the outermost wire gets corrupted or a corrupt wire is generated.

ulrich1a

2013-07-07 08:59

reporter   ~0003347

From the debugging session it seems w2.isnull() checks, if the pointer is equal to "UndefinedHandleAddress". But the pointer was 0x0, which is different to UndefinedHandleAddress. My helping programmer changed the code of oce w2.isnull() to handle also the case the pointer is 0x0. But then the crash was due to 0x0 being in the pointer to the Location data.
At this stage we stopped digging further in.

wmayer

2013-07-07 17:29

administrator   ~0003352

I don't know why the sorting should invalidate the wires. So, to see if your assumption is right you can make two changes:
+ comment out the line "std::sort(wires.begin(), wires.end(), Wire_Compare());"
+ replace the line "wire_list.insert(wire_list.begin(), wires.rbegin(), wires.rend());"
with "wire_list.insert(wire_list.begin(), wires.begin(), wires.end());"

ulrich1a

2013-07-08 19:35

reporter   ~0003359

I made tests with just an array of circles.
An array of 1x100 circles does not crash.
An array of 100x1 circles does not crash.
An array of 2x50 circles crashes.

Deactivating the sorting does avoid the crash for the 2x50 array.

wmayer

2013-07-09 06:40

administrator   ~0003360

Hmmm, maybe the STL implementation on your system invalidates the stored wires!?
So, I made two changes:
1.) the class Wire_Compare now inherits from std::binary_function. If this doesn't solve the issue then try the 2nd change.

2.) there is an alternative sort algorithm implemented. To activate it replace the "#if 1" with "#if 0" (look for the line: 'bug 0001133: try alternative sort algorithm' and go up 6 lines)

ulrich1a

2013-07-21 07:21

reporter   ~0003420

I got time now to test again. Just compile after git pull does not solve the issue.
But activating the alternative sort algorithm solves the issue on my system. skizzy.py runs without problems. Thank you for solving this.

I had a chance to test on a Debian wheezy 64bit installation. There was no problem with a standard compile. So it seems the problem is related to Debian (Linux) 32bit-installations.

wmayer

2013-09-03 13:00

administrator   ~0003542

A workaround is available (but not active be default).

Issue History

Date Modified Username Field Change
2013-05-19 15:05 ulrich1a New Issue
2013-05-19 15:05 ulrich1a File Added: skizze.py
2013-05-21 10:08 wmayer Note Added: 0003171
2013-05-24 21:30 normandc Note Added: 0003178
2013-05-24 21:31 normandc File Added: skizze-alternate.fcstd
2013-05-24 21:33 normandc Note Added: 0003179
2013-06-26 13:05 Jriegel Note Added: 0003253
2013-06-26 13:05 Jriegel Status new => feedback
2013-06-26 13:06 Jriegel Note Added: 0003254
2013-06-30 18:32 ulrich1a Note Added: 0003301
2013-07-01 06:53 wmayer Note Added: 0003302
2013-07-02 18:02 ulrich1a File Added: backtrace_segfault_skizze.py.txt
2013-07-02 18:12 ulrich1a Note Added: 0003325
2013-07-03 03:57 wmayer Note Added: 0003326
2013-07-03 12:07 jannekro Note Added: 0003327
2013-07-03 20:08 ulrich1a File Added: bt3_full_SIGSEGV_skizze.py.txt
2013-07-03 20:21 ulrich1a Note Added: 0003329
2013-07-04 04:20 wmayer Note Added: 0003330
2013-07-06 17:08 ulrich1a Note Added: 0003341
2013-07-07 07:03 wmayer Note Added: 0003345
2013-07-07 08:46 ulrich1a Note Added: 0003346
2013-07-07 08:59 ulrich1a Note Added: 0003347
2013-07-07 17:29 wmayer Note Added: 0003352
2013-07-08 19:35 ulrich1a Note Added: 0003359
2013-07-09 06:40 wmayer Note Added: 0003360
2013-07-21 07:21 ulrich1a Note Added: 0003420
2013-09-03 13:00 wmayer Note Added: 0003542
2013-09-03 13:00 wmayer Status feedback => closed
2013-09-03 13:00 wmayer Resolution open => fixed
2013-09-03 13:00 wmayer Fixed in Version => 0.14