MantisBT - Community
View Issue Details
0023855Community[OCCT] OCCT:Modeling Algorithmspublic2013-03-25 12:572014-05-05 13:37
WindowsVC++ 200864 bit
[OCCT] 6.6.0 
[OCCT] 6.7.1[OCCT] 6.7.1 
bugs modalg_5(010) bug23855
0023855: Old BOPs fail on Win7 64bit when using TBB
Old BOPs fail when using OCCT with TBB on an 64 bit Windows7.

Investigations show that the lines (30/31):

const TopOpeBRepDS_ListOfInterference* l1 = (const TopOpeBRepDS_ListOfInterference*)(*((long int*)v1));
const TopOpeBRepDS_ListOfInterference* l2 = (const TopOpeBRepDS_ListOfInterference*)(*((long int*)v2));

in TopOpeBRep_sort.cxx, in the compll-method obtain pointers that apparently do not point at valid objects and so the line 32 causes the exception:
if (l1->Extent() == 0) return (0);

The problem occurs only when MMGT_OPT=2.
32 bit version is not affected.
Make sure the following environment variables are set:

set MMGT_OPT=2

and then run DRAW:

pload ALL
psphere s1 10
psphere s2 10
common result s1 s2

... exception is thrown.

The script runs without problems if either MMGT_OPT=1 or MMGT_OPT=0.
No tags attached.
related to 0024066closed Pawel Memory corruption when using BRepPrimAPI package 
Issue History
2013-03-25 12:57PawelNew Issue
2013-03-25 12:57PawelAssigned To => bugmaster
2013-05-14 14:09PawelAssigned Tobugmaster => jgv
2013-05-14 14:09PawelProduct Version6.5.5 => 6.6.0
2013-05-14 14:09PawelTarget Version => 6.7.0
2013-06-03 01:39PawelNote Added: 0024595
2013-06-03 01:39PawelAssigned Tojgv => Roman Lygin
2013-06-03 01:39PawelStatusnew => feedback
2013-06-03 08:25Roman LyginNote Added: 0024596
2013-06-03 08:25Roman LyginAssigned ToRoman Lygin => jgv
2013-06-03 08:25Roman LyginStatusfeedback => assigned
2013-06-03 08:26Roman LyginNote Added: 0024597
2013-07-11 19:59PawelRelationship addedrelated to 0024066
2013-12-21 10:13abvTarget Version6.7.0 => 6.7.1
2013-12-22 18:05PawelNote Added: 0027294
2014-01-17 21:34Roman LyginNote Added: 0027542
2014-01-17 21:34Roman LyginStatusassigned => resolved
2014-01-17 22:46kgvNote Added: 0027543
2014-01-17 23:23Roman LyginNote Added: 0027544
2014-01-18 13:44abvNote Added: 0027549
2014-01-18 13:44abvAssigned Tojgv => bugmaster
2014-01-18 13:44abvStatusresolved => reviewed
2014-01-20 17:50mkvAssigned Tobugmaster => mkv
2014-01-20 18:00abvNote Added: 0027559
2014-01-22 10:57mkvNote Added: 0027587
2014-01-27 11:35mkvNote Added: 0027646
2014-01-27 11:36mkvTest case number => bugs modalg_5(010) bug23855
2014-01-27 11:36mkvAssigned Tomkv => bugmaster
2014-01-27 11:36mkvStatusreviewed => tested
2014-02-03 10:15bugmasterChangeset attached => occt master 091232ba
2014-02-03 10:15bugmasterStatustested => verified
2014-02-03 10:15bugmasterResolutionopen => fixed
2014-05-05 13:34aivStatusverified => closed
2014-05-05 13:37aivFixed in Version => 6.7.1

2013-06-03 01:39   
Dear Roman,

can I please ask you to check if you can confirm this problem?

I know you have great experience with Intel TBB so maybe you could give a hint what causes such behaviour.

Roman Lygin   
2013-06-03 08:25   
Hi Julia,
This has nothing to do with TBB actually. This code will equally fail with any allocator. TBB just seems to provoke it more aggressively, what is good.

The root-cause is likely the same as in 0022786: wrong pointer arithmetic and attempt to store a pointer in long int. On Windows 64, the size of long int is 32 bit so it loses part of the pointer.

It looks like it input parameters v1 and v2 are pointers to pointers, so following should work:
const TopOpeBRepDS_ListOfInterference* l1 = *(const TopOpeBRepDS_ListOfInterference**)(v1);

For C++ code you might want to prefer more strict reinterpret_cast<> to C-style casting:
const TopOpeBRepDS_ListOfInterference* l1 = *reinterpret_cast<const TopOpeBRepDS_ListOfInterference**>(v1);

But please check the semantics and test.
Hope this helps.
Roman Lygin   
2013-06-03 08:26   
Ohh, just realized that this was Pawel who reassigned this to me initially. Anyway, hope this will help to both of you, Pawel and Julia.
2013-12-22 18:05   
One observation: The problem does not occur with tbb42_20131003oss.
Roman Lygin   
2014-01-17 21:34   
I have just came across this issue when running the regression test on Windows 64bit:
test bugs fclasses bug23237

The fix has been pushed into the repository.
I have also fixed some warning "unreachable code" (interesting which the compiler did not trigger it on the original code).

As mentioned earlier, the root-cause has nothing to do with TBB. It's just plain wrong casting a pointer to long int which may fail on Windows 64 regardless of the underlying allocator.
2014-01-17 22:46   
Just small comment:
+  Standard_Address p = T;
+  Standard::Free(p);

the copy seems to be redundant since 0024489
Roman Lygin   
2014-01-17 23:23   
Right. However I intentionally left it as is, to ease backporting to previous versions of OCC (I had to apply it to 6.7.0 at least).
Re 0024489 I have a comment to be posted there.
2014-01-18 13:44   
Reviewed, please test. Sorry I have added one more commit to make the code around more readable (mostly adding line breaks between operators).
2014-01-20 18:00   
Please test also on 64-bit Windows!
2014-01-22 10:57   
Dear BugMaster,

Branch CR23855 (and products from GIT master) was compiled on Linux and Windows platforms and tested.
SHA-1: b83ea14c43780ba3334c951892e0047d7379da73

Number of compiler warnings:

occt component :
Linux: 48 (48 on master)
Windows: 1 (1 on master)

products component :
Linux: 12 (12 on master)
Windows: 2 (2 on master)

No regressions/differences

Testing cases:
Not needed

Testing on Linux:
Total MEMORY difference: 365200936 / 365947140
Total CPU difference: 43948.98999999988 / 44021.22000000015

Testing on Windows:
Total MEMORY difference: 417067404 / 417396220
Total CPU difference: 32577.796875 / 32472.65625

There are not differences in images found by testdiff.
2014-01-27 11:35   
Dear BugMaster,

Branch CR23855 (and products from GIT master) was compiled on 64-bit Windows platform and tested.
No regressions/differences

Testing cases:
bugs modalg_5 bug23855 - OK.