How do I get rid of this error?
Is the fact that I'm not running with graphics a problem? I'm only running command line linux. IE No xwindows. the computer is only for crunching.
Thanks for the help.
Cadeus
PS How do I find this post again to see if it is answered Is there an easy way?
Host ID=391055
the error...
4.43
process exited with code 22 (0x16)
dlopen() failed: libGL.so.1: cannot open shared object file: No such file or directory
No graphics.
graphics_lib_handle NULL: running without graphics
Detected CPU type 1
APP DEBUG: Application caught signal 4
Stack trace of LAL functions in worker thread:
TestLALDemod at line 755 of file /home/bema/einsteinathome/CFS/EaH_build_release_4.89b/extra_sources/lalapps-CVS/src/pulsar/FDS_isolated/CFSLALDemod.c
At lowest level status code = 0, description: NO LAL ERROR REGISTERED
Obtained 10 stack frames for this thread.
Use gdb command: 'info line *0xADDRESS' to print corresponding line numbers.
einstein_4.81_i686-pc-linux-gnu[0x80532f5]
/lib/libpthread.so.0[0x40043f54]
/lib/libc.so.6[0x400786b8]
einstein_4.81_i686-pc-linux-gnu[0x804c428]
einstein_4.81_i686-pc-linux-gnu[0x8052e0d]
einstein_4.81_i686-pc-linux-gnu[0x80edcbc]
einstein_4.81_i686-pc-linux-gnu[0x80edbfd]
einstein_4.81_i686-pc-linux-gnu[0x8053172]
/lib/libc.so.6(__libc_start_main+0xbb)[0x4006814f]
einstein_4.81_i686-pc-linux-gnu[0x804b301]
Copyright © 2024 Einstein@Home. All rights reserved.
Code 22 fix?
)
No, running without graphics shouldn't be a problem.
However it seems that our SSE detection reports SSE to be present while the CPU gives an "illegal instruction" when executing our code. This is most likely a problem of our App which hasn't shown up during the Beta Testing. Thanks a lot for your report!
What CPU are you running it on?
Probably the easiest is to subscribe to the thread you created. You will get emailed when someone posts to it with, I think, a link you can simply click on.
BM
BM
RE: What CPU are you
)
He is running it on computer ID 391055, reported as a Pentium III (Coppermine).
I had been delving into his computers from his earlier message and had seen the text and was about to suggest to him that he should post the full error message when I noticed that he had already done so. Just goes to show the value of posting full error messages when something "unusual" comes along. Well done Cadeus.
Cheers,
Gary.
RE: No, running without
)
Same here: AMD K6-233
and according to the debugger it crashes here:
Wurgl: Not really the same.
)
Wurgl: Not really the same. Your CPU has been (correctly) detected as "CPU type 0" (see stderr output), which means that the App should use the generic version of the code. It already crashed in CreateDemodParams() which is quite a bit earlier than TestLALDemod(). I'm not sure yet if this is a problem of our App or the machine, I'll need to dig a bit deeper there.
BM
BM
Gary: Thanks, I should have
)
Gary:
Thanks, I should have seen this myself (still jetlagged, apparently).
Cadeus:
Figures, I found a machine here which has the same problem - and the same CPU. Most likely the gcc-4 compiler (falsely) generates SSE2 code, but we only look for SSE. So this should be a problem on all machines which have SSE, but not SSE2, like the PIII. Watch out for the next Linux Beta App, I'll post a message here, too.
Wurgl:
Can it be that with "-mfpmath=sse -march=pentium3" the gcc-4.0 actually includes SSE2 instructions, or at least requires a later version of P III than Coppermine?
BM
BM
RE: Cadeus: Figures, I
)
Not likely ... see this coppermine. No problems with the new app ...
Metod ...
RE: Gary: Wurgl: Can it be
)
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 6
model name : AMD-K6tm w/ multimedia extensions
stepping : 2
cpu MHz : 233.867
cache size : 64 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 mce cx8 mmx
bogomips : 466.94
No idea, during debugging I saw this line:
Loaded symbols for /lib/ld-linux.so.2
0x0805d8c2 in TestLALDemod_for_cpu_type_0 ()
(gdb) cont
Continuing.
It seems to be strange, I could ans still cannot believe that a sinple floating point instruction causes a segmentation fault.
But it is not important, the machine is so slow that it would not help the project very much.
Sorry that it took us so long
)
Sorry that it took us so long - it's holiday time and we are still quite busy...
Anyway: Please check out our Beta Test Page. Ther you'll find an App which allows to manually override the CPU detection and force it to use generic code.
From the whole pool of machines we have I only know of precisely two machines (PIII Coppermine) which have the SSE bit set in the CPUID feature bitmask but file a "signal 4" (illegal instruction) when actually executing SSE instructions. One of these is located at the AEI and has definietly gotten too hot a while ago. Might be some sort of temperature instability. Anyway, if you run into problems, check this out.
BM
BM
RE: Sorry that it took us
)
Can you set the executable flag inside the tar archive?
I think that einstein_0.15_i686-pc-linux-gnu should have mode 755 instead of 644
BTW:
2005-09-01 12:45:16 [Einstein@Home] execv(../../projects/einstein.phys.uwm.edu/einstein_0.15_i686-pc-linux-gnu) failed: -1
Isn't here a ../ too much?
RE: Can you set the
)
Thanks for spotting this! - done.
The softlink is in BOINC/slots/0 , so ../../ referrs back to BOINC/
BM
BM