|
Pages: [1]
|
 |
|
Author
|
Topic: UQM 0.3, threads, linux, and pxa_250 CPU (Read 3221 times)
|
|
|
|
|
|
|
Culture20
Enlightened
 Offline
Posts: 917
Thraddash Flower Child
|
I just noticed the message "WARNING: SetSemaphore did not return 0, this could be bad!" hiding in the output. 
I assume SDL_SemWait seems to be the culprit, but I don't know if having SDL 1.2.4 on the compile machine and SDL 1.2.6 on the running machine would cause the problem... Well, the SDL I'm using is experimental anyway (it uses Qt, not X). I'll try installing X versions of the SDL library that match the version I'm compiling with. That way, external errors can be ruled out.
|
|
|
|
|
Logged
|
|
|
|
|
|
Culture20
Enlightened
Offline
Posts: 917
Thraddash Flower Child
|
I would if I knew how. I'm embarassed to say that I don't use gdb that often. 
Here are my attempts to do a trace (editing out my attempts to read the in-gdb help menus):
Starting program: /mnt/ramfs/usr/bin/uqm-debug --res=320x240 --speechvol=0 -q=high --cscan=pc --music=pc --menu=pc --contentdir=/mnt/ramfs/usr/share/uqm/content --sound=none -f
The Ur-Quan Masters v0.3 (compiled Sep 9 2003 16:02:05)
This software comes with ABSOLUTELY NO WARRANTY;
for details see the included 'COPYING' file.
Saved games are kept in /home/c20/.uqm/save/.
Initializing SDL (pure).
SDL driver used: x11
SDL initialized.
Initializing Screen.
Set the resolution to: 320x240x16
WARNING: SetSemaphore did not return 0, this could be bad!
Initializing MixSDL mixer.
MixSDL using driver 'NoSound'
MixSDL mixer initialized.
opened 'fake' at 44100 Hz 16 bit stereo, 4096 samples audio buffer
Initializing sound decoders.
Sound decoders initialized.
0 joysticks were found.
'lbm/scclrtab.ct' -- 8722 bytes
We've loaded the Kernel
'lbm/title.ani' -- 19 bytes
'arilou.shp' -- 301 bytes
'arilou/ariicons.ani' -- 50 bytes
'arilou/arimicon.ani' -- 46 bytes
'arilou/aritext.txt' -- 407 bytes
'arilou/arilou.cod' -- 1 bytes
Program received signal SIGSEGV, Segmentation fault.
Cannot access memory at address 0x40035ee0
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) down
No stack.
(gdb) frame
No selected frame.
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) select-frame
No selected frame.
(gdb) up
No stack.
(gdb) select-frame 1
Cannot access memory at address 0x40035ee0
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) select-frame 2
Cannot access memory at address 0x40035ee0
(gdb) select-frame 3
Cannot access memory at address 0x40035ee0
(gdb) bt
Cannot access memory at address 0x40035ee0
(gdb) up
No stack.
(gdb) down
No stack.
To someone who's never used a stack-trace before, it looks to me that there either isn't a stack, or it's only one entry big (which if the ship/race loading is stack based would make sense: only 1 ship/race is getting loaded, the arilou). This also looks nothing like the similar run on my linux desktop. It had a lot of thread creation:
[New Thread 114696 (LWP 1357)]
[New Thread 131081 (LWP 1358)]
[New Thread 147466 (LWP 1359)]
.
.
.
Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 1343)]
0x402115b1 in select () from /lib/libc.so.6
(gdb) bt
#0 0x402115b1 in select () from /lib/libc.so.6
#1 0x4006fedc in __JCR_LIST__ () from /usr/lib/libSDL-1.2.so.0
#2 0x080d97b5 in SDLWrapper_TaskSwitch ()
#3 0x080a4066 in TFB_FlushGraphics ()
#4 0x0804b99a in main ()
#5 0x401564ed in __libc_start_main () from /lib/libc.so.6
I've installed a completely new GUI, X11 based instead of Qt based, and the SDL libraries are X11 based, as can be read. Maybe helpfull; Someone wrote this on the familiar (handheld linux) mailing list today:
I've run into what appears to be a bug with pthreads under a rather specific situation. In particular, pthread_create() does not return under familiar 0.7.1 after a call to popen(). The same code, when running on familiar 0.5.3, works just fine. Some google searching turned up someone who had a similiar issue and included a small example program illustrating the bug:
http://sources.redhat.com/ml/libc-alpha/2003-02/msg00042.html
Despite claims that the poster's sample code was buggy, it does in fact illustrate buggy pthread_create() behavior. In fact, one of the respondants suggests that there is a bug in linuxthreads:
http://sources.redhat.com/ml/libc-alpha/2003-02/msg00047.html
While this sounds like an issue with pthread in particular versus familiar in general, I'm left with a quandary regarding upgrading to 0.7.1, sticking with 0.5.3, trying 0.6, etc. Given this seems to be a genuine bug that would prevent me from using familiar 0.7.1, I'm writing to (1) alert others of this bug, and (2) solicit opinions on the best way to proceed at this point.
My program uses pthreads and executes commands via popen(). It also runs on Opie. Ideally, I would have liked to just use the familiar 0.7.1 Opie image. Clearly, that's not possible.
I notice pthread 0.10 is included with familiar 0.7.1 and pthread 0.9 is included with 0.5.3. I suppose one possibility would be to compile pthread 0.9 for use under 0.7.1. I'm not sure how big of an undertaking that would be or if it would address the problem at hand.
This seems earily similar to what you mentioned first, Meep-Eep, maybe I should have listened. Got any URL's to explain stripped vs. non-stripped libraries? If stripping a library reduces its size by making dummy function calls w/o any code, that could explain a few things; this OS has to live in limited space... The ipaq does have /lib/libpthread.so.0 which is a symlink to /lib/libpthread-0.10.so, just in case "stripping" them means that pthreads doesn't exist.
While uqm doesn't seem to use any popen()'s or pthread_create()'s explicitly (I grepped the source to make sure), SDL threads might... So, this problem could very well be intrinsic to the OS I'm using, and have nothing to do with UQM whatsoever.
|
|
|
|
« Last Edit: September 13, 2003, 09:37:51 am by Culture20 »
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
There are actually several stacks, one for every thread.
A problem is that when one thread crashes, and you get the gdb prompt, the others are still running.
I thought that we never killed a thread from the outside anymore (but instead signalling a thread that it has to terminate itself), but it does look like the stack of the thread that crashed is already gone.
Stripping a file will remove its symbols, and it's indeed something that is done to save space. But it often makes debugging a lot more complicated.
In this particular case, I'm not even sure gdb handles it correctly.
You can count on SDL using functions like pthread_create(), but popen() has nothing directly to do with pthreads.
As for URLs, how about this one: http://groups.google.com/groups?threadm=3f301790$0$40216$39cecf19@news.twtelecom.net
Btw, if you come to #sc2 on irc.freenode.net, I might be able to help you in real-time.
|
|
|
|
« Last Edit: September 14, 2003, 06:41:11 am by meep-eep »
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
|
|
|
|
|
|
Culture20
Enlightened
Offline
Posts: 917
Thraddash Flower Child
|
Sorry, didn't clarify; Since the machine that I compiled UQM on didn't have a stripped pthreads, that's where I ran the program to get the last gdb info w/backtrace. It's another pxa_250 based iPAQ, but it's not mine...
I'll try looking at the code some more, but unfortunately, I'm not a good low-level programmer. I'll see if any of the handhelds.org people who have ported other programs can offer any quick tips. Thanks for helping, Meep-Eep.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|
