[Bug 723] New: parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

Summary: parser-test.exe fails on Win32 MinGW
Product: RTT
Version: 1.10.1
Platform: i386 Compatible
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P3
Component: Tests
AssignedTo: orocos-dev [..] ...
ReportedBy: uwe_kindler [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Created an attachment (id=533)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=533)
Stack trace copied from QtCreator debug console

On execution of the test cases on a Win32 machine all tests passed except of
the parser-test.exe. This test failed with segmentation fault. I started the
debugger to find the reason for the crash. The test crashes on line 275 of
dispatch_test.cpp.

I can set a breakpoit on line 275 and the execution stops on this breakpoint.
If I try to step into the function parser.parseProgramm( prog, tc) the debugger
stops with "signal-received" and the following stack trace (see attachment).

The Orocos library and the tests was build with:

CMAKE_BUILD_TYPE Debug
CMAKE_CXX_FLAGS_DEBUG -g3 -O0

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution| |FIXED
Status|NEW |RESOLVED

--- Comment #10 from Peter Soetens <peter [..] ...> 2010-06-18 14:16:53 ---
Reporter confirmed bug is fixed on trunk.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #9 from Peter Soetens <peter [..] ...> 2010-05-03 11:44:40 ---
(In reply to comment #8)
> Created an attachment (id=550)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=550)
> Stack trace (gcc 3.4.1 boost 1.36)
>
> I compiled the OROCOS library and the tests with a MinGW installation with GCC
> 3.4.1 and Boost 1.36 to check if the parser-test.exe failure is a compiler (GCC
> 4.4.0) or boost (1.40) issue.
>
> I got the same result on running the tests - all tests passed except of
> parser-test.exe that fails with SEGFAULT. I ran parser-test.exe via GDB to the
> point where it fails. It fails at another location then it failed before when
> compiled with GCC 4.4.0 and Boost 1.40. Attached is the stack trace right before
> the last single stepping command that causes the crash.
>
> Now I'm also out of options.

We fixed a bug a few weeks ago in the parser that caused crashes in
multi-threaded programs calling the parser API... I don't know if it is related
to this, but maybe it was. These fixes are on svn trunk, not on the 1.10
branch...

Peter

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #8 from Uwe Kindler <uwe_kindler [..] ...> 2009-11-08 13:54:37 ---
Created an attachment (id=550)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=550)
Stack trace (gcc 3.4.1 boost 1.36)

I compiled the OROCOS library and the tests with a MinGW installation with GCC
3.4.1 and Boost 1.36 to check if the parser-test.exe failure is a compiler (GCC
4.4.0) or boost (1.40) issue.

I got the same result on running the tests - all tests passed except of
parser-test.exe that fails with SEGFAULT. I ran parser-test.exe via GDB to the
point where it fails. It fails at another location then it failed before when
compiled with GCC 4.4.0 and Boost 1.40. Attached is the stack trace right
before the last single stepping command that causes the crash.

Now I'm also out of options.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #7 from Peter Soetens <peter [..] ...> 2009-11-02 11:14:27 ---
(In reply to comment #6)
> Created an attachment (id=540)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=540)
> Stack trace after throw patch applied (static linked)
>
> I applied your throw patch and linked the parser-test.exe with the static OROCOS
> library but the test still fails with SegFault - I attached a stack trace.

I'm out of options. I'll need a gcc 4.4 + boost 1.40 setup myself to test your
case. It looks like I'll need to work around a compiler bug or work around a
change in boost.

Peter

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #6 from Uwe Kindler <uwe_kindler [..] ...> 2009-10-30 19:08:26 ---
Created an attachment (id=540)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=540)
Stack trace after throw patch applied (static linked)

I applied your throw patch and linked the parser-test.exe with the static
OROCOS library but the test still fails with SegFault - I attached a stack
trace.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #5 from Peter Soetens <peter [..] ...> 2009-10-30 16:05:07 ---
Created an attachment (id=538)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=538)
Rewrites throw_ to be sure it throws the right exception type.

It may be that with newer compilers/boost versions, throw_ throws the wrong
exception type. This patch makes sure that the correct type is thrown.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

Uwe Kindler <uwe_kindler [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #534 is|0 |1
obsolete| |

--- Comment #4 from Uwe Kindler <uwe_kindler [..] ...> 2009-10-30 08:49:03 ---
Created an attachment (id=537)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=537)
Stack trace after patch applied

I applied your patch but the parser-test.exe still fails. I attached a new
stack trace.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

--- Comment #3 from Peter Soetens <peter [..] ...> 2009-10-29 23:28:10 ---
Created an attachment (id=536)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=536)
Patch to apply to make sure the unit test is correct

Apply this with patch -p1 < tweak-dispatch-test.patch

recompile and re-run the parser-test.exe

This is to exclude that the final crash is caused by the unit test itself. If
not, we need to dig further.

Peter

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

Uwe Kindler <uwe_kindler [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #533 is|0 |1
obsolete| |

--- Comment #2 from Uwe Kindler <uwe_kindler [..] ...> 2009-10-29 14:11:43 ---
Created an attachment (id=534)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=534)
Stack trace (-g -O1)

Here is the new stack trace after rebuild with -g -O1. If I debug the
parser-test.exe then the last line that I can set a breakpoint to is line 159
in ValueParser.cpp. This is the place where an exception is thrown and the
application crashes.

[Bug 723] parser-test.exe fails on Win32 MinGW

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=723

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...

--- Comment #1 from Peter Soetens <peter [..] ...> 2009-10-29 12:41:22 ---
(In reply to comment #0)
> Created an attachment (id=533)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=533) [details]
> Stack trace copied from QtCreator debug console
>
> On execution of the test cases on a Win32 machine all tests passed except of
> the parser-test.exe. This test failed with segmentation fault. I started the
> debugger to find the reason for the crash. The test crashes on line 275 of
> dispatch_test.cpp.
>
> I can set a breakpoit on line 275 and the execution stops on this breakpoint.
> If I try to step into the function parser.parseProgramm( prog, tc) the debugger
> stops with "signal-received" and the following stack trace (see attachment).
>
> The Orocos library and the tests was build with:
>
> CMAKE_BUILD_TYPE Debug
> CMAKE_CXX_FLAGS_DEBUG -g3 -O0

Could you edit src/CMakeLists.txt and change the line:
SET_SOURCE_FILES_PROPERTIES( $ENV{GLOBAL_SCRIPTING_SRCS} PROPERTIES
COMPILE_FLAGS "-g1 -O2" )
to:
SET_SOURCE_FILES_PROPERTIES( $ENV{GLOBAL_SCRIPTING_SRCS} PROPERTIES
COMPILE_FLAGS "-g -O1" )

and recompile, retest and re-send the backtrace ?

Thanks !

Peter