Hi Jakob Both "trace_file_label.txt" and "trace_file_new_label.txt" should have the same information since they execute the same code
Currently (in the updated version), they don't. Something else might be interfering in the trace file generation Sincerely, Marcelo d'Almeida On Thu, Mar 4, 2021 at 6:34 PM Marcelo Andrade Rodrigues D Almeida < [email protected]> wrote: > Thank you > > Tomorrow I'll start new tests with the new development version to debug > the original issue > > On Thu, Mar 4, 2021, 6:06 PM Jakob Erdmann <[email protected]> wrote: > >> Thanks for the example. The problem was due to >> https://github.com/eclipse/sumo/issues/8320 >> >> Am Do., 4. März 2021 um 20:16 Uhr schrieb Marcelo Andrade Rodrigues D >> Almeida <[email protected]>: >> >>> I could reproduce the trace file problem >>> >>> See attached files >>> >>> >>> >>> >>> >>> On Thu, Mar 4, 2021 at 3:29 PM Marcelo Andrade Rodrigues D Almeida < >>> [email protected]> wrote: >>> >>>> Just to clarify >>>> >>>> The attached file is one of the finished tests from the last batch >>>> (traceGetters False) >>>> >>>> But both (this one and the previously traceGetters True) were >>>> presenting zero simulation step entries in the trace files. >>>> >>>> >>>> >>>> On Thu, Mar 4, 2021 at 3:21 PM Marcelo Andrade Rodrigues D Almeida < >>>> [email protected]> wrote: >>>> >>>>> I'm redoing the tests with traceGetters set to False to reduce the >>>>> (huge) file size. Also, I had to restart the tests because someone or >>>>> something turned off the remote machine overnight. >>>>> >>>>> >>>>> What I could find so far: >>>>> >>>>> I could retrieve a trace file in the remote server (the huge one) and >>>>> I found something very odd. >>>>> >>>>> In my trivial test, I found a regular trace file >>>>> >>>>> "traci.start(['/home/marcelo/code/sumo/bin/sumo-gui', '-n', >>>>> '/home/marcelo/temp2/temp/temp/temp/regular-intersection__right_on_red.net.xml', >>>>> '-r', '/home/marcelo/temp2/temp/temp/temp/regular-intersection.rou.xml', >>>>> '--start', 'True'], port=None, label='default') >>>>> traci.trafficlight.setPhase('gneJ0', 0) >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.trafficlight.setPhase('gneJ0', 0) >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.simulationStep() >>>>> traci.trafficlight.setPhase('gneJ0', 0) >>>>> " >>>>> >>>>> In my actual experiment (with multi_processing set to False), all >>>>> 'traci.simulationStep()' commands are gone (see file attached for complete >>>>> trace): >>>>> " >>>>> traci.trafficlight.setRedYellowGreenState('231', >>>>> 'rrrrGGggrrrGGGgyyyyrrrrGGGGggrrrrrrrrrrrrGGg') >>>>> traci.trafficlight.setRedYellowGreenState('231', >>>>> 'rrrrGGggrrryyyyyyyyrrrrGGGGggrrrrrrrrrrrrGGg') >>>>> traci.trafficlight.setRedYellowGreenState('233', 'rryyyyrrrryy') >>>>> traci.trafficlight.setRedYellowGreenState('282', 'rrryyyrrryyy') >>>>> traci.trafficlight.setRedYellowGreenState('221', >>>>> 'yyyrrrryyyyyyyrrrrryyy') >>>>> traci.trafficlight.setRedYellowGreenState('220', 'GGGrrrrryyyrr') >>>>> traci.trafficlight.setRedYellowGreenState('209', 'ryrGGrr') >>>>> traci.trafficlight.setRedYellowGreenState('210', >>>>> 'rrrGGGGGrrrrrrrryyyy') >>>>> traci.trafficlight.setRedYellowGreenState('273', 'yyyrrrryy') >>>>> traci.vehicle.subscribe('Prati_Capraia_100_70', [66, 64, 122, 86, 183, >>>>> 76, 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Borgo_20_56', [66, 64, 122, 86, 183, 76, 72, >>>>> 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Malvasia_100_70', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Pertini_20_159', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Costa_700_126', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Pepoli_10_199', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Gandhi_40_219', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Audinot_3_16', [66, 64, 122, 86, 183, 76, 72, >>>>> 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Pepoli_10_200', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.vehicle.subscribe('Silvani_7_145', [66, 64, 122, 86, 183, 76, >>>>> 72, 68, 81, 71, 77, 67, 181]) >>>>> traci.trafficlight.setRedYellowGreenState('231', >>>>> 'rrrrGGggrrryyyyrrrrGGrrGGGGggrrrrrrrrrrrrGGg') >>>>> traci.trafficlight.setRedYellowGreenState('231', >>>>> 'rrrrGGggrrrrrrrrrrrGGrrGGGGggrrrrrrrrrrrrGGg') >>>>> traci.trafficlight.setRedYellowGreenState('282', 'GGgrrrGGgrrr') >>>>> traci.trafficlight.setRedYellowGreenState('220', 'GGGrrrrGrrrrr') >>>>> traci.trafficlight.setRedYellowGreenState('209', 'GrGGGrr') >>>>> traci.trafficlight.setRedYellowGreenState('210', >>>>> 'rrrGGGGGrrrrrrGGrrrr') >>>>> traci.trafficlight.setRedYellowGreenState('273', 'rrrGGGGrr') >>>>> traci.trafficlight.setRedYellowGreenState('233', 'GGrrrrGGGgrr') >>>>> traci.trafficlight.setRedYellowGreenState('221', >>>>> 'rrrGGGGrrrrrrrGGGGGrrr') >>>>> " >>>>> >>>>> This was the reported crash from this execution: >>>>> #0 0x000055d660c7cf86 in MSVehicle::getBoundingBox() const () >>>>> #1 0x000055d660cfa5b1 in MSLane::detectCollisions(long long, >>>>> std::__cxx11::basic_string<char, std::char_traits<char>, >>>>> std::allocator<char> > const&) () >>>>> #2 0x000055d660cd8b54 in MSEdgeControl::detectCollisions(long long, >>>>> std::__cxx11::basic_string<char, std::char_traits<char>, >>>>> std::allocator<char> > const&) () >>>>> #3 0x000055d660c34294 in MSNet::simulationStep() () >>>>> #4 0x000055d660c344a6 in MSNet::simulate(long long, long long) () >>>>> #5 0x000055d660c1c37d in main () >>>>> >>>>> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>> >>>>> What I could find about the trace file generation problem >>>>> >>>>> The problem is that (without multi-processing) traci is discarding the >>>>> first run trace file info and keeping traces for the following runs. >>>>> When running with multi-processing, all traci simulations are handled >>>>> as first-run (i.e., new processes) and everything is thrown away. >>>>> >>>>> It doesn't matter if it is a regular or a debug build >>>>> >>>>> I'm don't know why the first run is discarded. I'll keep looking >>>>> >>>>> >>>>> Any new information, I post here >>>>> >>>>> >>>>> On Wed, Mar 3, 2021 at 10:08 AM Jakob Erdmann <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Harald, >>>>>> the loop with the AnyVehicleIterator should never yield nullptrs. >>>>>> Hence the real bug is someplace else. >>>>>> The 4 worker threads in the stacktrace are due to >>>>>> --device.rerouting.threads', '4', which doesn't really help to explain >>>>>> this >>>>>> (parallel routing typically doesn't cause premature vehicle deletion). >>>>>> Had the threads come from option --threads, that would have been a >>>>>> likely cause of the issue since we have far fewer tests for this. >>>>>> >>>>>> neverthless @marcello: Please try running without option >>>>>> --device.rerouting.threads and see if you can still trigger the crash. >>>>>> >>>>>> Either way, I will probably need a traci-traceFile to fix this. >>>>>> >>>>>> regards, >>>>>> Jakob >>>>>> >>>>>> Am Mi., 3. März 2021 um 13:55 Uhr schrieb Harald Schaefer < >>>>>> [email protected]>: >>>>>> >>>>>>> Hi Marcelo, hi Jakob, >>>>>>> >>>>>>> thanks for the backtraces (looks good) >>>>>>> >>>>>>> The problem in this scenario is that MSVehicle::getBoundingBox >>>>>>> (this=0x0) is called with a null-Object from this loop: >>>>>>> >>>>>>> for (AnyVehicleIterator veh = anyVehiclesBegin(); veh != >>>>>>> anyVehiclesEnd(); ++veh) { >>>>>>> MSVehicle* collider = const_cast<MSVehicle*>(*veh); >>>>>>> //std::cout << " collider " << collider->getID() << >>>>>>> "\n"; >>>>>>> PositionVector colliderBoundary = >>>>>>> collider->getBoundingBox(); >>>>>>> >>>>>>> Thread 1 (Thread 0x7fb4974cd780 (LWP 12544)): >>>>>>> #0 0x0000561970425dcc in MSVehicle::getBoundingBox (this=0x0) at >>>>>>> /app/sumo-git/src/microsim/MSVehicle.cpp:5925 >>>>>>> #1 0x00005619704c23f5 in MSLane::detectCollisions >>>>>>> (this=0x561972d88020, timestep=947000, stage="move") at >>>>>>> /app/sumo-git/src/microsim/MSLane.cpp:1358 >>>>>>> Regards, Harald >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> sumo-user mailing list >>>>>> [email protected] >>>>>> To unsubscribe from this list, visit >>>>>> https://www.eclipse.org/mailman/listinfo/sumo-user >>>>>> >>>>> _______________________________________________ >>> sumo-user mailing list >>> [email protected] >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user >>> >> _______________________________________________ >> sumo-user mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> >
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
