|
From: Bill S. <bil...@my...> - 2005-09-06 18:33:11
|
Hi all, i'm having some troubles with Valgrind and the code of the recently started game OpenAnno [1]. I already searched the FAQ and the mailing list for an answer to this, but i didn't find anything that seems to be related to my problem. If this is a common issue i apologize ahead. I attached the error below, if you need more info i will try to provide it. Thanks for your help, Werner Höhrer [1] http://www.lanadminsystem.de/cgi-bin/Lanas.pl?OPENANNO This output is what i get when i run # valgrind -v --tool=none ./openanno (It really doesn't depend on the tool i use, the error is displayed anyway) BEGIN error------------------------------------- ... ... Skipped some parts that care related to other errors (i think). ... I can post them as well if needed. ... vex: priv/host-x86/hdefs.c:2315 (emit_X86Instr): Assertion `0' failed. vex storage: P 512, T total 411183672 (13013711), T curr 20960 (702) valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==7591== at 0xB0016A22: vgPlain_core_panic_at (m_libcassert.c:181) ==7591== by 0xB0016A21: panic (m_libcassert.c:177) ==7591== by 0xB0016A3F: vgPlain_core_panic_at (m_libcassert.c:182) ==7591== by 0xB0016A50: vgPlain_core_panic (m_libcassert.c:187) ==7591== by 0xB002394C: failure_exit (m_translate.c:360) ==7591== by 0xB00573FA: vex_assert_fail (vex_util.c:163) ==7591== by 0xB005B8F1: emit_X86Instr (hdefs.c:2315) ==7591== by 0xB0057039: LibVEX_Translate (vex_main.c:574) ==7591== by 0xB0023ED1: vgPlain_translate (m_translate.c:585) ==7591== by 0xB0038F2E: handle_tt_miss (scheduler.c:566) ==7591== by 0xB003925A: vgPlain_scheduler (scheduler.c:680) ==7591== by 0xB004F475: vgModuleLocal_thread_wrapper (syswrap-linux.c:80) ==7591== by 0xB004B9E2: run_a_thread_NORETURN (syswrap-x86-linux.c:150) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==7591== at 0x1B97EAF9: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97EDE7: SDL_HasMMX (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B94ECF5: SDL_CalculateBlitN (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B938CB4: SDL_CalculateBlit (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B952653: SDL_MapSurface (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B952E3C: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B955113: SDL_Flip (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x804DFB3: clientstart (client.c:220) ==7591== by 0x804A004: main (openanno.c:57) Thread 2: status = VgTs_Runnable ==7591== at 0x1BC84F87: select (in /lib/tls/libc-2.3.5.so) ==7591== by 0x1B97E1A6: SDL_Delay (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97E1F9: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97CDC6: SDL_RunThread (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97D0FB: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B9D9CCC: start_thread (in /lib/tls/libpthread-2.3.5.so) ==7591== by 0x1BC8CB0D: clone (in /lib/tls/libc-2.3.5.so) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. END error------------------------------------- |
|
From: Bill S. <bil...@my...> - 2005-09-06 18:37:59
|
Of course i forgot to add the info about Valgrid and my system: valgrind-3.0.1 debian (testing/unstable) kernel 2.6.11-1-k7 gcc (GCC) 4.0.2 20050821 (prerelease) (Debian 4.0.1-6) Werner |
|
From: Tom H. <to...@co...> - 2005-09-06 18:46:34
|
In message <431...@my...>
Bill Spam <bil...@my...> wrote:
> i'm having some troubles with Valgrind and the code of the recently
> started game OpenAnno [1].
>
> I already searched the FAQ and the mailing list for an answer to this,
> but i didn't find anything that seems to be related to my problem.
> If this is a common issue i apologize ahead.
> I attached the error below, if you need more info i will try to provide it.
Can you raise a bug for this on the bug tracker please?
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bill S. <bil...@my...> - 2005-09-06 22:22:52
|
Tom Hughes wrote: > Can you raise a bug for this on the bug tracker please? Ok, done that :) http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=46268&atid=445586 > Tom Thanks, Werner |
|
From: Julian S. <js...@ac...> - 2005-09-06 22:48:18
|
> Tom Hughes wrote: > > Can you raise a bug for this on the bug tracker please? > > Ok, done that :) > http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=4 >6268&atid=445586 Werner Thanks for that. Unfortunately Tom meant on the KDE bugzilla, (bugs.kde.org), which is where all Valgrind bugs "live". Anyway: I guess you are running this on a non-SSE capable CPU, correct? [no problem -- just want to check.] The assertion that failed merely guards a case for which the code exists, but no test case has been found (until now): case Xin_MFence: /* see comment in hdefs.h re this insn */ if (0) vex_printf("EMIT FENCE\n"); switch (i->Xin.MFence.subarch) { case VexSubArchX86_sse0: vassert(0); /* awaiting test case */ <--- HERE /* lock addl $0,0(%esp) */ *p++ = 0xF0; *p++ = 0x83; *p++ = 0x44; *p++ = 0x24; *p++ = 0x00; *p++ = 0x00; goto done; If you remove the line marked HERE, and rebuild everything, does it work? It would be good if you could confirm that. J |
|
From: Oswald B. <os...@kd...> - 2005-09-07 05:48:49
|
On Tue, Sep 06, 2005 at 11:48:46PM +0100, Julian Seward wrote: > Thanks for that. Unfortunately Tom meant on the KDE bugzilla, > (bugs.kde.org), which is where all Valgrind bugs "live". > ugh, the sf tracker is not disabled? shame on you. :) hmm, either the sf frontend is too cryptic for me or one can't, indeed, remove the tracker without asking the sf team (yes, i tried on one of my own projects i have admin perms on ;). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Olly B. <ol...@su...> - 2005-09-07 13:21:11
|
On 2005-09-07, Oswald Buddenhagen <os...@kd...> wrote: > On Tue, Sep 06, 2005 at 11:48:46PM +0100, Julian Seward wrote: >> Thanks for that. Unfortunately Tom meant on the KDE bugzilla, >> (bugs.kde.org), which is where all Valgrind bugs "live". >> > ugh, the sf tracker is not disabled? shame on you. :) > hmm, either the sf frontend is too cryptic for me or one can't, indeed, > remove the tracker without asking the sf team (yes, i tried on one of my > own projects i have admin perms on ;). You can disable the SF trackers if you are a project admin (the UI isn't particularly obvious though). It's documented here: https://sourceforge.net/docman/display_doc.php?docid=14041&group_id=1#tracker Cheers, Olly |
|
From: <bil...@my...> - 2005-09-07 15:43:01
|
Julian Seward wrote: >>Tom Hughes wrote: >> > Can you raise a bug for this on the bug tracker please? >> >>Ok, done that :) >>http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=4 >>6268&atid=445586 > > > Werner > > Thanks for that. Unfortunately Tom meant on the KDE bugzilla, > (bugs.kde.org), which is where all Valgrind bugs "live". > > Anyway: I guess you are running this on a non-SSE capable CPU, > correct? [no problem -- just want to check.] I don't think so (Athlon K7 != SSE ?): # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor stepping : 1 cpu MHz : 656.746 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow bogomips : 1294.33 > The assertion that failed merely guards a case for which the > code exists, but no test case has been found (until now): > > case Xin_MFence: > /* see comment in hdefs.h re this insn */ > if (0) vex_printf("EMIT FENCE\n"); > switch (i->Xin.MFence.subarch) { > case VexSubArchX86_sse0: > vassert(0); /* awaiting test case */ <--- HERE > /* lock addl $0,0(%esp) */ > *p++ = 0xF0; *p++ = 0x83; *p++ = 0x44; > *p++ = 0x24; *p++ = 0x00; *p++ = 0x00; > goto done; > > If you remove the line marked HERE, and rebuild everything, > does it work? It would be good if you could confirm that. Ah, thanks for the answer. I'm currently using the (unstable) debian package of valgrind, but if i find some time i'll try to compile with this change. I've seen this workaround a few times until now (searched again today), so i'm pretty sure this'll fix my problem though. Thanks for your effort, Werner PS: As a few of you have seen already i've added a bug report into the KDE Bugzilla now. |
|
From: Tom H. <to...@co...> - 2005-09-07 16:07:29
|
In message <431...@my...>
Werner H=C3=B6hrer <bil...@my...> wrote:
> Julian Seward wrote:
>
> > Thanks for that. Unfortunately Tom meant on the KDE bugzilla,
> > (bugs.kde.org), which is where all Valgrind bugs "live".
> >
> > Anyway: I guess you are running this on a non-SSE capable CPU,
> > correct? [no problem -- just want to check.]
>
> I don't think so (Athlon K7 !=3D SSE ?):
Yup.
> flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
> cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow
No SSE flag there - mmxext is a subset of SSE1.
What you've got looks like an early Athlon - only the later XP/MP
ones had the full SSE1 instruction set.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <bil...@my...> - 2005-09-07 17:25:13
|
Tom Hughes wrote: >>flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca >>cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow > > > No SSE flag there - mmxext is a subset of SSE1. > > What you've got looks like an early Athlon - only the later XP/MP > ones had the full SSE1 instruction set. You are right, it is one of the first series of Athlons. It's still running like a charm and is performing quite well with my TNT2. Quote from http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions "AMD eventually added support for SSE instructions in its Athlon XP processor." On a sidenote: I can even run Q3, Nexuiz and similar games with a good framerate, but none of the newer features of course ;) Werner |