Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] No longer when Sumo-gui crashes
If you can manage to use the python bindings for traci, this allows for logging of all traci calls that were sent to sumo, making it much easier to reproduce problems: https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#generating_a_log_of_all_traci_commands.
However, if you are managing to crash sumo with moveToXY calls, then it may be enough to provide the network file and a sequence of coordinates that you used.

Am Di., 28. Feb. 2023 um 12:15 Uhr schrieb Ruud van Gaal <r.vangaal@xxxxxxxxxx>:
Hi Jakob,

Flushing the general log file will cause stutters; we tend to avoid that here and write the log in a separate thread actually to keep things running in realtime. We do have a LogSynchronous() call which we can use in case severe crashes cause the log thread to miss that latest log message you are probably most interested in. For the error-log default explicit flushes may make more sense since you shouldn't normally get errors when things are ready for production.

Thanks for the tip on running SUMO instead of the GUI, hadn't thought of that.

There was no content in the log file (it was created but stayed at 0 bytes) although the simulation did start and ran for a little while. Later on, I saw an exception about a setRouteID() that failed, probably due to a funny location (I'm steering the human-controlled vehicle off the road sometimes with MoveToXy() and SetSpeed()). That might be a thing for later; any Vehicle::MoveToXy() call with KeepRoute other than 0 (so 2, 4, 6) will crash SUMO here quite quickly even when hitting the sidewalk (so close to the route's edge). Unfortunately a simple reproduction case is difficult since I have multiple applications that work in concert in our simulation.

Thanks!
Ruud


On Tue, Feb 28, 2023 at 11:54 AM Jakob Erdmann <namdre.sumo@xxxxxxxxx> wrote:
Hi,
there is currently no option for flushing the log file (though maybe this should be the default anyway: https://github.com/eclipse/sumo/issues/12714)
stdout and stderr are supposed to flush after every simulation step. So instead of using sumo-gui you could run sumo where the log goes to stdout/stderr
However, the log file is rarely enough to diagnose a gui crash anyway. A reproducible example is needed instead.
If there is no log file at all despite running with verbose, then possibly the simulation failed to start properly.



Am Di., 28. Feb. 2023 um 10:16 Uhr schrieb Ruud van Gaal <r.vangaal@xxxxxxxxxx>:
Hi,

I'm investigating an issue on Windows where SUMO-GUI crashes at some point. I don't get a log file though when it crashes. I run with these arguments:

Starting SUMO with these arguments:
  sumo-gui
  -c
  cruden_world_2.sumocfg
  --step-length
  0.100000
  --time-to-teleport
  -1
  --lanechange.duration
  2.000000
  --verbose
  true
  --log
  sumo_lastrun.log
  --start
  --quit-on-end

When killing sumo-gui for example from the TaskManager, the 'sumo_lastrun.log' file doesn't appear; so any last-minute exception that might have occurred is lost. When closing normally, the log file is written correctly.

Is there a mode or argument to enforce a flush of the log file after each message for example?

Thanks,
Ruud

_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top