I do my best to avoid these evil things, but it seems we've a big problem ! (Houston)
Here, under Linux, when I try to launch "./odyncomp.sh rrp_play.c --file demo.rrp", I get a segault.
Here's the back trace:
Code:
#0 0xb71abc8a in raydium_math_quaternion_slerp (start=0xb782f180,
end=0xb782f190, alpha=0, result=0x3fa05a90) at raydium/math.c:402
#1 0xb719c114 in raydium_ode_capture_internal_move_all (diff=0.031940937)
at raydium/ode.c:5459
#2 0xb719c3e1 in raydium_ode_capture_seek (time=2.3343980312347412)
at raydium/ode.c:5547
#3 0xb719cd43 in raydium_ode_capture_play_callback () at raydium/ode.c:5776
#4 0xb7180f19 in raydium_callback_image () at raydium/callback.c:50
#5 0xb71a53ce in raydium_rendering_finish () at raydium/render.c:410
#6 0x08049157 in display () at rrp_play.c:88
#7 0xb7181027 in raydium_callback_internal_loop_wrapper ()
at raydium/callback.c:106
#8 0xb71badf4 in glutManualLoop () at raydium/myglut.c:68
#9 0xb71bae06 in glutMainLoop () at raydium/myglut.c:77
#10 0xb718109f in raydium_callback (loop=0x8048ed6) at raydium/callback.c:128
#11 0x080492c6 in main (argc=1065059329, argv=0xbb0a70ec) at rrp_play.c:124
... and the crash itself :
Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1236830480 (LWP 12048)]
0xb71abc8a in raydium_math_quaternion_slerp (start=0xb782f180, end=0xb782f190,
alpha=0, result=0x3fa05a90) at raydium/math.c:402
402 result[0] = ((start[0] * startWeight) + (end[0] * endWeight));
My GCC :
Code:
Target: i586-manbo-linux-gnu
Configuré avec: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=i586-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp
Modèle de thread: posix
version gcc 4.2.3 (4.2.3-6mnb1)
After a few tests, the problem is "result", that generates the segfault when I try to read or write.
The crash only occurs with dynamic Shared Object compilation (odyncomp), not with "hard" linking (ocomp).
The bug seems present since commit 738 (where trigo.c was changed to math.c), but since we talk about memory corruption, the bug is maybe here since a long time, and commit 738 only reveal it.
Can anyone is able reproduce this bug (Linux and win32) ?
As such thing is very dangerous, it may lead to various instabilities, we must quickly find what's happens here !