Fri 21 Dec 2007 04:56:41 PM UTC, comment #14:
Okay, I checked out your new commit. And, congratulation, you killed the bug :). For me, everything works as before. No crashes anymore.
Many thanks for your chrismas gift :)!
|
Fri 21 Dec 2007 02:33:24 PM UTC, comment #13:
I have found 3 errors in strlen in Message, FederationsList and FederationManagement that could explain the crash.
As it is a memory overflow, under some systems, the crash does not occurs.
PS : Yes, Eric, I say, I will use strings....
I wait Christian's confirmation.
I have made commit.
JY
|
Fri 21 Dec 2007 02:10:00 PM UTC, comment #12:
I am not sure,but I have seen other :
In RTIG/FederationsList.cc (line 352) I wrote :
FED_Filename = new char[strlen(federation->getFEDid()+1)] ;
instead of :
FED_Filename = new char[strlen(federation->getFEDid())+1] ;
Aîe ! aïe !!!
Could you try it. Here, no different execution !!!
|
Fri 21 Dec 2007 01:59:07 PM UTC, comment #11:
Me again,
I've a suspicion. Could it be that the return value
of the method info in
RTIG/FederationsList.cc causes such strange behaviour?
There a pointer is returned to a char. But the memory is allocated
within the method. Normally, such memory is freed in the further
execution or will be overwritten because all allocated memory is only valid in the function.
So could it be possible that this value is overwritten? This would explain the differnet errors I had (segmentation violation, vanished fed file). In my first attachment of the log files you can see that the content of filename changed while executing the RTIG_processing method (I added some output in RTIG_processing.cc). Perhaps that's the reason. I will check it tomorrow.
A+
|
Fri 21 Dec 2007 12:52:21 PM UTC, comment #10:
Here comes the diff
(file #14679)
|
Fri 21 Dec 2007 12:39:14 PM UTC, comment #9:
Hi,
you can be lucky, we have maybe 1°C. This is definetly to cold for me. But perhaps we get a white christmas, so this is obviously impossible for you :). But the chances are still very small when living 10 km in the south of the coast of the baltic sea.
I think this error has something to do with the last changes, I'm wondering it is not reproduceable for you.
I've made the following steps:
Made a fresh cvs co and compiled the sources with cmake in my certi build dir. After that, I get the described fault behaviour.
After that I changed to my certi sources dir and typed
cvs update -D "10 day ago"
I compiled certi again. And all works fine. After that I repeated the operations with
cvs update -D "9 days ago" and I've gotten the same errors.
So the changes between these two days are responsible for the behaviour. I will check the return values as you said and I will made a diff of the changes between these two days. Hope to find the error still today.
Hope you will have some calm christmas days away from any keyboard, I will try it but I can not assure it, it's my passion.
How do you celebrate new year in France? In Germany the blow up rockets at every corner, I do not like that really. For such things people here spent a lot of money.
A+
|
Fri 21 Dec 2007 12:17:09 PM UTC, comment #8:
The main corrections I have made concern dynamic allocation of FED file name and federation name.
Maybe I have made a bug in memory allocation but I can't reproduce the problem.
This morning I have tryed billard, your last version of TP HLA and others tests with no problem.
We are closed until 1/1/2008, but I can work at home, so this afternoon I will see.
Coul you verify the return value of fonction info ? Here it is good but maybe...
Jean-Yves
PS : How is the weather ? Here sunny (10°) but wind...
|
Fri 21 Dec 2007 09:47:19 AM UTC, comment #7:
Okay,
it's strange, seems like a glibc library problem or some
memory allocation errors. I get the different errors sometimes at joining the federation or after registering a sync point.
|
Fri 21 Dec 2007 09:28:53 AM UTC, comment #6:
Hello Rousse,
thanks for your efforts.
At first I've done the advice you had gave me. Billard crashes too. But now I get a glibc error.
I'm a little bit confused, mysteriously seems the right term :). I've taken a clean debian box and made a co, compiled the whole as you said with autogen && configure && make && make install.
There billard and rtig crashes too.
After that I downloaded certi-3.2.5, compiled it and everything works fine.
Perhaps tody I find a reason, I will see.
|
Fri 21 Dec 2007 06:44:31 AM UTC, comment #5:
I can't reproduce the bug !
Coul you try this :
Launch rtig in directory where Test.fed is.
Launch also billard in directory where Test.fed is.
File vanished means Test.fed was found by rtig during create federation execution and not found by rtig during join federation execution...
to be continued
|
Thu 20 Dec 2007 05:51:14 PM UTC, comment #4:
I just try it on my PC under Fedora at home and billard is ok !!
I have started from zero : rm of all directory containing old version.
co from Savannah, autogen, configure, make install.
Billard runs without pb.
??!!
I will try it to morrow on Solaris and Fedora 64
to be continued and mysteriously....
JY
|
Thu 20 Dec 2007 04:36:13 PM UTC, comment #3:
To morrow, I will see the Pb.
JY
|
Thu 20 Dec 2007 11:49:05 AM UTC, comment #2:
Hello Eric,
I suppose I've done all the necessary steps.
I've made
$build_certi/cmake ~/certi
after that a make && make install.
Before that I also deleted my build directory.
I've also removed my certi dir and made a fresh cvs
checkout.
After that, I've recompiled the whole sources with the
above steps.
Additionally, I called ldconfig and also I checked
all binaries (billard, rtig) with ldd.
I will look at that problem in depth. I attach the debug output.
I suppose there is a problem in rtig. As you can see in the
file rtig.debug there is probably a problem with the variable
filename in RTIG_processing.cc. I added some output in the sources.
One last but important thing:
Enjoy your holiday and don't waste your time with my little
certi probs, there will be a new year :) and of course
I wish you all joyeux Noël et une bonne et heureuse année.
A bientot
Christian
(file #14673, file #14674)
|
Thu 20 Dec 2007 10:49:42 AM UTC, comment #1:
Hi Christian,
I'm on holiday with not that much time
to compile/test certi.
I'll try to chekc this out but
could you check you don't have a
old/new shared library mismatch?
The most common case is to use a freshly
compiled billard dynamically linked with old
libCERTI.so library.
(because LD_LIBRARY_PATH wasn't update or make install is missing)
|
Wed 19 Dec 2007 09:26:51 PM UTC, original submission:
Hello,
today I came back to CERTI. At first I made a checkout
of the certi tree.
After that I started rtig and tried to run the billard
demo by calling
billard -f test -n test1 -F Test.fed
After that billard and rtia crash. The following output
is produced:
CERTI Billard 3.2.6cvs
with TIMESTAMP. If you want without TIMESTAMP add -e option.
terminate called after throwing an instance of 'certi::NetworkError'
libRTI: exception: NetworkError (read)
Billard::main: RTI exception: RTIinternalError [libRTI: Network Read Error waiting RTI reply].
Exiting.
Also rtig crashes with a segmentation violation.
I tested on two different linux (debian) boxes (home, work), so
the error should be reproduceable.
|