-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when loading layout file #545
Comments
I'm seeing similar issues on Ubuntu with |
Hi @jmailloux The layout you shared don't contain the information about the file, therefore I assume you first load the file and then load the layout. I can not reproduce the error. Can you send the entire backtrace? |
Hi @facontidavide. All I have to do is load the layout file. There is no log file if that is what you are asking. If I load a log file first, then load the layout file. Same thing happens. Here is the stack trace: Stack trace (most recent call last): |
I tried this on an Ubuntu VM. Layout file is slightly different than what I posted above. I loaded the layout file. Plotjuggler hung this time. I tried loading a log file, then loading the layout file. Plotjuggler crashed |
ok. First of all, the layout don't crash with latest version of PlotJuggler. On the other hand, I can see a limitation of the Layout + Custom Series, that fails when one custom series depend on another, as in your case. Let me see if I can fix the later issue. |
@facontidavide , thanks for the patch. The first thing I did after opening PlotJuggler after I rebuilt it is try to open efficiency.xml (without loading a data file). It crashed. See below stack trace. Should I open another issue? Stack trace (most recent call last): |
I then reopened plotjuggler, loaded log_12. Then loaded efficiency.xml. It crashed. Stack trace (most recent call last): |
I am sorry that you still have problems, but unfortunately I can not reproduce this on my side, therefore I can hardly find a solution. The only thing that I noticed here in your backtrace is that there is not reference to PlotJuggler at all. Sorry |
OK. Thanks. I'd be happy to run experiments if you had anything you wanted to try. Only other thing to note is I have an ARM based machine. I wonder if doing what I am doing is causing memory corruption. What is getting corrupted when you try to reproduce is not causing problems. What is getting corrupted when I try to reproduce causes a crash. I have a colleague who also see crashes in plotjuggler. He is running Windows on x86. I can see if he can reproduce the crash using the same reproduction steps I am using if that would help. |
On MacOS, plotjuggler 3.2.0, if I load the xml, then the log, it crashes with this stack trace. If I load the log, then the xml, it doesn't crash. But if I then load another log, it crashes with the same stack trace. |
Ok , this last piece of information give me some hint.... I wonder where this |
just to be sure: DO NOT USE 3.2.0. Use master only, compiled in debug mode by yourself. Otherwise, it could be an issue I solved already and we are wasting time. |
Got it. Definitely don't want to waste your time. The Linux crashes have all been from master that I compiled myself. The MacOS one was also from master, but from a while ago, that I compiled myself. I can update to latest on MacOS and try if that would help. Just to clarify - when you say compiled in debug mode - I compile by following the instructions on the github page. I don't do anything different. |
Please compile like this
This should provide much more informative backtrace. Aldo consider that loading the layout BEFORE the data is NOT expected to work properly. |
OK. On the first try, the debug version on Ubuntu did not crash. :) I will keep using it and report if it crashes. |
OK. Got a crash after loading a different log: ==8886==ERROR: AddressSanitizer: heap-use-after-free on address 0xffff6799b380 at pc 0xaaaae1f4b284 bp 0xfffff89ec040 sp 0xfffff89ec060 0xffff6799b380 is located 192 bytes inside of 232-byte region [0xffff6799b2c0,0xffff6799b3a8) previously allocated by thread T0 here: SUMMARY: AddressSanitizer: heap-use-after-free /usr/include/c++/9/bits/stl_list.h:942 in std::__cxx11::list<PJ::PlotWidgetBase::CurveInfo, std::allocatorPJ::PlotWidgetBase::CurveInfo >::begin() |
I have found a pretty serious bug and (fingers crossed) this MIGHT be related to yours. Can you try the latest main with 2ca9a91 ? |
Hello @facontidavide, your changes seem to fix the crash. However, if I do the following: |
Loading the log file, then the layout still crashes on MacOS. Stack trace (most recent call last): |
I still can't reproduce the issue in Lua, but I added something that you will like: pj_reload-2021-11-01_16.06.41.zip Loading a different file with almost the same data should work now and Custom curves are recalculated, as they should. |
I am closing this because now it is a duplicate of other issues |
I have similar issue with this, while I tried to use the UDP streaming, plotjuggler crash after I click the start button. I tried with this solution, but it didn't solve my crash problem. @facontidavide, is there any other suspicious problem that I might be able to fix? I am currently using a Mac M1 Pro. |
Thanks for contributing to PlotJuggler. You are great!
Problem description
I save a layout file that has a Custom Series called Power (save custom transformations option is selected. It multiplies current and voltage. I then close plotjuggler and reopen it, and load the layout file. It crashes in lua_rawgeti.
I've attached the layout file.
This is using main. The crash does not happen on 3.2.
Steps to reproduce (important)
See description
Describe your platform / Operative System.
I'm using MacOS Big Sur. I know MacOS isn't supported. Submitting this in case it happens on other platforms as well.
Check if the problem can be reproduced using the dummy data created by the command line argument "-t" or one of the files in the folder "datasamples".
If it can't be reproduced with the dummy data, please share the CSV file or the rosbag that can be used to reproduce the problem.
layouts.zip
The text was updated successfully, but these errors were encountered: