Hello Jakob,
I can confirm that this has fixed my crashing issue!
That's just amazing!
Thank you so much for your incredible support!
I really appreciate it!
Best regards
Marcel
--
Sent from: http://sumo-user-mailing-list.90755.n8.nabble.com/
___
Today's version already includes the crash fix. The other issue is fixed on
github now (https://github.com/eclipse/sumo/issues/7075) and you can
download the updated version tomorrow.
Am Di., 26. Mai 2020 um 11:41 Uhr schrieb marcelreppi :
> Hello Jakob,
>
> thank you so much for looking into it
I have experimented some more with my code to find the issue.
I feel like I have found the problem but I am not 100% sure.
My SUMO config has the following parameters at the start of the simulation:
*
*
During the simulation I am trying to "turn off" the rerouting device for
some
I have put together a small scenario.
Please find some further information in the README.
The scenario was too big to attach here so I uploaded it to my cloud:
https://u.pcloud.link/publink/show?code=XZEAYqkZhi7JpWGDfpSA3xJiW5uCtuSork4k
Thank you very much for looking into it!!
I am eagerly
I will try to create a portable scenario that is as small as possible and
post it here.
It must be related to TraCI rerouting, because as soon as I turn it off it
seems to be running fine.
Thank you very much!
--
Sent from: http://sumo-user-mailing-list.90755.n8.nabble.com/
I was able to recreate the other error. Here is the stacktrace:
Step #900.00 (8ms ~= 125.00*RT, ~1000.00UPS, TraCI: 5ms, vehicles TOT
Step #1000.00 (3ms ~= 333.33*RT, ~2333.33UPS, TraCI: 5ms, vehicles TO
Step #1100.00 (2ms ~= 5corrupted size vs. prev_size
Program received signal SIGABRT,
Thanks for the backtrace
Unfortunately, it was not enough for me to pinpoint the source of the error
(even though it points at the rough area).
I will need to replicate the crash on my own machine and would need a
suitable scenario (including traci script) for this. The smaller you can
make it,
Unfortunately I had already closed that terminal.
I tried running it again but I could not get the exact same error. I will
try to recreate it.
I got a different error though. Here is the stacktrace for it:
Warning: At actuated tlLogic 'joinedS_7', linkIndex 16 has no controlling
detector
Step
After the crash while still in gdb, create a backtrace by typing
'bt' 'enter'
and then post the output.
Am Mi., 20. Mai 2020 um 13:20 Uhr schrieb marcelreppi :
> That worked!
>
> Thank you very very much for replying so quick and helping!
> I really appreciate it!!
>
> It crashed giving me the
That worked!
Thank you very very much for replying so quick and helping!
I really appreciate it!!
It crashed giving me the following error:
Step #3000.00 (6ms ~= 166.67*RT, ~833.33UPS, TraCI: 6ms, vehicles TOT 50 ACT
5 BUFStep #3100.00 (2ms ~= 500.00*RT, ~2000.00UPS, TraCI: 5ms, vehicles TOT
After starting gdb you have to press 'r' followers by 'enter' to make sumo
run and open up the port.
Am Mi., 20. Mai 2020 um 12:42 Uhr schrieb marcelreppi :
> I thought so and that's also exactly what I did.
> The numRetries=100 is helpful, thanks!
>
> It's constantly trying to connect to a
I thought so and that's also exactly what I did.
The numRetries=100 is helpful, thanks!
It's constantly trying to connect to a different port and re-writing the
debug.sumocfg. Even after I executed the gdb command.
I can see the following warning/error
The build is ok (the enabled features are sufficient for your needs).
To make the debugging work you need to start the traci script in one shell
and start the debugger in another shell while the script still tries to
reconnect. You either have to be quick for this or set a higher number of
I followed the build instructions here
https://sumo.dlr.de/docs/Installing/Linux_Build.html#building_the_sumo_binaries_with_cmake_recommended
I am doing all of this in WSL Ubuntu.
When executing "cmake -D CMAKE_BUILD_TYPE=Debug ../.." I got the following
output:
*
-- CMAKE_BINARY_DIR:
No. The next step would be to run sumo in a debugger and the connecting
your traci script.
(see
https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#debugging_a_traci_session_on_linux
)
If you can manage to put together a small scenario that crashes "reliably"
(i.e after running it a
No not really... only about 180MB.
When I try to change the arrival times or the amount of trips it affects the
error.
Sometimes it doesn't occur at all, sometimes earlier, sometimes later.
What also happens very often is that TraCI crashes only saying
"traci.exceptions.FatalTraCIError:
Is your simulation using a lot of memory?
Can you make the simulation fail earlier/more often or later/less often by
changing the scenario size?
Am Di., 19. Mai 2020 um 12:03 Uhr schrieb marcelreppi :
> Hello,
>
> my TraCI implementation suddenly quits at random timesteps with "Error: bad
>
17 matches
Mail list logo
