PedestrianDynamics / jupedsim

JuPedSim is an open source pedestrian dynamics simulator
http://jupedsim.org
Other
39 stars 27 forks source link

Loading and parsing the project file Segmentation fault: 11 #475

Closed gjaeger closed 4 years ago

gjaeger commented 5 years ago

JuPedSim - JPScore

Current date : Aug 14 2019 09:10:01 Version : 0.8.4 Commit hash : v0.8.4-164-g082762a9 Commit date : Wed Aug 14 08:43:29 2019 Branch : develop

After compiling with gcc (see #470 and #473), I can no longer run the program.

For demo scenario_1_corridor:

$ jpscore corridor_ini.xml

I get without log-file: INFO: Loading and parsing the project file <corridor_ini.xml>Segmentation fault: 11

chraibi commented 5 years ago

Interesting!

When compiled with AppleClang

Current date   : Aug 14 2019 17:00:18
Version        : 0.8.4
Commit hash    : v0.8.4-164-g082762a9
Commit date    : Wed Aug 14 14:43:29 2019
Branch         : develop
----

everything runs well!

gjaeger commented 5 years ago

I can confirm that.

schroedtert commented 5 years ago

https://github.com/JuPedSim/jpscore/blob/082762a9d03b957c86e2202ddb9c2cfdaf7d0620/IO/IniFileParser.cpp#L82-L92

The q.parent_path() is empty when using boost. Then trying to call fs::absolute on an empty paths causes the SegFault. Edit: The previous assumption was wrong. Even if q.parent_path() is empty fs::absolute returns a valid path when using Clang.

schroedtert commented 5 years ago

The error is maybe caused, when boost is not compiled with the same flags as JPScore. If I remember correctly @Ozaq mentioned something similar in an other issue/PR.

https://stackoverflow.com/a/19470480

Ozaq commented 5 years ago

To understand what happened it is very helpful to have a stack trace of the call that triggered the crash. Could you enable coredumps on your machine (https://stackoverflow.com/questions/9412156/how-to-generate-core-dumps-in-mac-os-x) and add the stack traces to this issue?

Once you have coredumps enabled you can open the dump with lldb -c <corefle> when attached you call bt (for backtrace) and paste the stacktrace.

schroedtert commented 5 years ago

Sorry for the late reply. Here are the results of the core dump:

[tobias@ias7143 scenario_2_bottleneck](develop)$ ../../build-dev-gcc/bin/jpscore bottleneck_ini.xml 

INFO:   Loading and parsing the project file <bottleneck_ini.xml>Segmentation fault: 11 (core dumped)
[tobias@ias7143 scenario_2_bottleneck](develop)$ lldb -c /cores/core.754 
(lldb) target create --core "/cores/core.754"
Core file '/cores/core.754' (x86_64) was loaded.
(lldb) bt --all
error: bt [<digit> | all]
(lldb) bt all
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff6b2ded0d libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 77
    frame #1: 0x0000000100dfdb86 jpscore`std::char_traits<char>::copy(__s1="", __s2="", __n=87) at char_traits.h:352:49
    frame #2: 0x0000000100fddb9b jpscore`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy(__d="", __s="", __n=87) at basic_string.h:340:21
    frame #3: 0x0000000100dfdb32 jpscore`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_copy_chars(__p="", __k1="", __k2="") at basic_string.h:382:16
    frame #4: 0x0000000100fe5806 jpscore`void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(this=0x00007ffeeee07310, __beg="", __end="", (null)=forward_iterator_tag @ 0x00007ffeeee07120) at basic_string.tcc:225:6
    frame #5: 0x0000000100e05927 jpscore`void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(this=0x00007ffeeee07310, __beg="", __end="", (null)=__false_type @ 0x00007ffeeee07160) at basic_string.h:236:11
    frame #6: 0x0000000100fddacf jpscore`void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(this=0x00007ffeeee07310, __beg="", __end="") at basic_string.h:255:4
    frame #7: 0x0000000100eb24af jpscore`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(this=0x00007ffeeee07310, __str=0x00007ffeeee07330) at basic_string.h:440:9
    frame #8: 0x0000000100e5e907 jpscore`IniFileParser::Parse(this=0x00007fa766c02d70, iniFile=string @ 0x00007ffeeee07560) at IniFileParser.cpp:92:32
    frame #9: 0x0000000100e0bccc jpscore`ArgumentParser::ParseArgs(this=0x00007fa766c02d20, argc=2, argv=0x00007ffeeee07948) at ArgumentParser.cpp:104:33
    frame #10: 0x0000000100dfad75 jpscore`main(argc=2, argv=0x00007ffeeee07948) at main.cpp:63:32
    frame #11: 0x00007fff6b0f63d5 libdyld.dylib`start + 1
    frame #12: 0x00007fff6b0f63d5 libdyld.dylib`start + 1
(lldb) 
Ozaq commented 5 years ago

@schroedtert didn't we fix this?

chraibi commented 4 years ago

@schroedtert do we still have this problem?

gjaeger commented 4 years ago

The described problem with gcc persists. I am currently compiling with AppleClang only.

Ozaq commented 4 years ago

@zeroset I think we can close this

chraibi commented 4 years ago

I think we can close this.