Archived issue #0032678

Coding Rules, ApproxInt_SvSurfaces - eliminate GCC -fsanitize=undefined error

CommunityOCCT:Codingclosed12 public notes

Search issues

Description

Errors reported by compiling with -fsanitize=undefined using g++ 11 (as well as clang 13 on macOS) and running our test suite:

src/ApproxInt/ApproxInt_SvSurfaces.hxx:92:12: runtime error: load of value 94, which is not a valid value for type 'bool'
src/ApproxInt/ApproxInt_SvSurfaces.hxx:92:12: runtime error: load of value 136, which is not a valid value for type 'bool'
src/ApproxInt/ApproxInt_SvSurfaces.hxx:92:12: runtime error: load of value 88, which is not a valid value for type 'bool'

This looks like it might be an issue of uninitialized data, but I've not looked at it closely.

Steps to reproduce

Compile with "-fsanitize=undefined -fno-omit-frame-pointer" and run your test suite.

Public activity

12 archived notes

Participants are labeled by their role within this record.

01Commenter 1
Branch [archived branch] has been created by Commenter 2.

[revision removed]


Detailed log of new commits:

Author: Commenter 2
Date: Mon Nov 22 02:13:56 2021 +0300

    0032678: Coding Rules, ApproxInt_SvSurfaces - eliminate GCC -fsanitize=undefined error
02Commenter 2
Could you check if this error is caused by uninitialized variable (branch CR32678) or something else?
03Author
valgrind did sussed out uninitialized data, but I'm not sure if it's the same problem...

==2972465== Conditional jump or move depends on uninitialised value(s)
==2972465== at 0x60AE2DC: GeomInt_TheMultiLineOfWLApprox::MakeMLBetween(int, int, int) const (ApproxInt_MultiLine.gxx:321)
==2972465== by 0x609C98E: GeomInt_TheMultiLineToolOfWLApprox::MakeMLBetween(GeomInt_TheMultiLineOfWLApprox const&, int, int, int) (ApproxInt_MultiLineTool.lxx:116)
==2972465== by 0x60979F0: GeomInt_TheComputeLineBezierOfWLApprox::Perform(GeomInt_TheMultiLineOfWLApprox const&) (Approx_ComputeLine.gxx:941)
==2972465== by 0x60B5F80: GeomInt_WLApprox::buildCurve(opencascade::handle<IntPatch_WLine> const&, void*) (ApproxInt_Approx.gxx:648)
==2972465== by 0x60B4C9F: GeomInt_WLApprox::Perform(opencascade::handle<Adaptor3d_Surface> const&, opencascade::handle<Adaptor3d_Surface> const&, opencascade::handle<IntPatch_WLine> const&, bool, bool, bool, int, int) (ApproxInt_Approx.gxx:337)
==2972465== by 0x5C7A7FB: IntTools_FaceFace::MakeCurve(int, opencascade::handle<Adaptor3d_TopolTool> const&, opencascade::handle<Adaptor3d_TopolTool> const&, double) (IntTools_FaceFace.cxx:1260)
==2972465== by 0x5C7745A: IntTools_FaceFace::Perform(TopoDS_Face const&, TopoDS_Face const&, bool) (IntTools_FaceFace.cxx:561)
==2972465== by 0x5D5F14A: BOPAlgo_FaceFace::Perform() (BOPAlgo_PaveFiller_6.cxx:187)
==2972465== by 0x5D64ACB: BOPTools_Parallel::Functor<NCollection_Vector<BOPAlgo_FaceFace> >::operator()(int) const (BOPTools_Parallel.hxx:40)
==2972465== by 0x5D652AF: OSD_Parallel::FunctorWrapperForThreadPool<BOPTools_Parallel::Functor<NCollection_Vector<BOPAlgo_FaceFace> > >::operator()(int, int) const (OSD_Parallel.hxx:256)
==2972465== by 0x5D6522F: OSD_ThreadPool::Job<OSD_Parallel::FunctorWrapperForThreadPool<BOPTools_Parallel::Functor<NCollection_Vector<BOPAlgo_FaceFace> > > >::Perform(int) (OSD_ThreadPool.hxx:299)
==2972465== by 0x579CBD1: OSD_ThreadPool::performJob(opencascade::handle<Standard_Failure>&, OSD_ThreadPool::JobInterface*, int) (OSD_ThreadPool.cxx:286)
==2972465== Uninitialised value was created by a stack allocation
==2972465== at 0x60B46DB: GeomInt_WLApprox::Perform(opencascade::handle<Adaptor3d_Surface> const&, opencascade::handle<Adaptor3d_Surface> const&, opencascade::handle<IntPatch_WLine> const&, bool, bool, bool, int, int) (ApproxInt_Approx.gxx:230)
==2972465==
04Author
Any luck with this? Would you like me to try to narrow down which variable on the stack is not initialized in GeomInt_WLApprox::Perform?
05Commenter 2
If CR32678 doesn't change anything, then no, I don't know yet where to look at.

.gxx files is a legacy of statically generated templates (by WOK), so that apart from cryptic sanitizer logs, it is difficult to read C++ code here - might be better to first rewrite the code with help of C++ templates.
06Author
Sorry I didn't notice the new constructor the first the I looked at CR32678. Yes this branch does fix both the undefined analyzer warning and valgrind also runs clean. I ran through our entire test suite to double check.
07Commenter 1
Branch [archived branch] has been updated forcibly by Commenter 2.

[revision removed]
08Commenter 2
> Yes this branch does fix both the undefined analyzer warning
Great, then let's merge the fix and register new issues of analyzer will find something more.
09Commenter 2
10Author
With this patch, all of our test suite runs clean. I will submit new issues if something comes up in the future. Thank you for all your help!
11Commenter 11
Combination -
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.

Number of compiler warnings:
No new/fixed warnings

Regressions/Differences/Improvements:
No regressions/differences

CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18222.380000000427 / 18166.60000000042 [+0.31%]
Products
Total CPU difference: 11645.100000000084 / 11658.820000000103 [-0.12%]
Windows-64-VC14:
OCCT
Total CPU difference: 19999.4375 / 19937.953125 [+0.31%]
Products
Total CPU difference: 13044.453125 / 13069.28125 [-0.19%]


Image differences :
No differences that require special attention

Memory differences :
No differences that require special attention
12Commenter 1
Branch [archived branch] has been deleted by Participant.

[revision removed]