One of the tests finished
NO_REROUTING_THREADS (see attached trace file)
Reading symbols from ../../sumo-git/bin/sumo...(no debugging
symbols found)...done.
[New LWP 3412]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `sumo-git/bin/sumo -n
/app/scenario/experimental/Bologna_small-0.29.0/joined/joi'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055a5cea65826 in MSVehicle::getBoundingBox() const ()
(gdb) bt
#0 0x000055a5cea65826 in MSVehicle::getBoundingBox() const ()
#1 0x000055a5ceae2e61 in MSLane::detectCollisions(long long,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) ()
#2 0x000055a5ceac13f4 in
MSEdgeControl::detectCollisions(long long,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) ()
#3 0x000055a5cea1c944 in MSNet::simulationStep() ()
#4 0x000055a5cea1cb56 in MSNet::simulate(long long, long
long) ()
#5 0x000055a5cea045ad in main ()
Still waiting on NO_MULTIPROCESS and
NO_REROUTING_THREADS_NO_MULTIPROCESS
Sincerely,
Marcelo d'Almeida
On Fri, Mar 5, 2021 at 11:03 AM Marcelo Andrade Rodrigues D
Almeida <[email protected] <mailto:[email protected]>> wrote:
It seems great!
Thank you!!
On Fri, Mar 5, 2021 at 9:48 AM Jakob Erdmann
<[email protected] <mailto:[email protected]>> wrote:
I think we're getting closer and closer to make
tracing work in your use case:
https://github.com/eclipse/sumo/issues/8323
<https://github.com/eclipse/sumo/issues/8323>
Am Fr., 5. März 2021 um 12:34 Uhr schrieb Marcelo
Andrade Rodrigues D Almeida <[email protected]
<mailto:[email protected]>>:
For instance, all but "traci.close()" and
"traci.simulationStep()" are duplicated in the
second run
On Fri, Mar 5, 2021 at 8:27 AM Marcelo Andrade
Rodrigues D Almeida <[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[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]
<mailto:[email protected]>> wrote:
Thanks for the example. The problem
was due to
https://github.com/eclipse/sumo/issues/8320
<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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>
To unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
_______________________________________________
sumo-user mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list,
visit
https://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
_______________________________________________
sumo-user mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
_______________________________________________
sumo-user mailing list
[email protected] <mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
_______________________________________________
sumo-user mailing list
[email protected] <mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
_______________________________________________
sumo-user mailing list
[email protected] <mailto:[email protected]>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/sumo-user
<https://www.eclipse.org/mailman/listinfo/sumo-user>
