FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001133 | FreeCAD | Bug | public | 2013-05-19 15:05 | 2013-09-03 13:00 |
| Reporter | ulrich1a | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.13 | ||||
| Fixed in Version | 0.14 | ||||
| Summary | 0001133: crash at padding a sketch with 42 holes | ||||
| Description | FreeCAD 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 Information | I am using freecad_0.13-git2118_i386.deb. at Debian wheezy 32 bit | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
2013-05-19 15:05
|
|
|
|
No crash here with Win7. Btw, your script creates a sketch with (7*7=) 49 holes. |
|
|
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
|
|
|
|
I attached the skizze-alternate.fcstd file because I was unable to make my recorded macro working. |
|
|
Can not reproduce, pad works for me (Windows 0.13) |
|
|
Works even with 10x10 holes... |
|
|
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. |
|
|
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
|
|
|
|
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. |
|
|
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 |
|
|
No problem here either. Random 0.13 version, and latest from git. Ubuntu 13.04. |
|
2013-07-03 20:08
|
|
|
|
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? |
|
|
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> |
|
|
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. |
|
|
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)); |
|
|
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. |
|
|
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. |
|
|
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());" |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
A workaround is available (but not active be default). |
| 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 |
|
Note Added: 0003253 | |
| 2013-06-26 13:05 |
|
Status | new => feedback |
| 2013-06-26 13:06 |
|
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 |
