The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
December 11, 2024, 10:28:40 am
Home Help Search Login Register
News: Celebrating 30 years of Star Control 2 - The Ur-Quan Masters

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  UQM 0.3, threads, linux, and pxa_250 CPU
« previous next »
Pages: [1] Print
Author Topic: UQM 0.3, threads, linux, and pxa_250 CPU  (Read 3311 times)
Culture20
Enlightened
*****
Offline Offline

Posts: 917


Thraddash Flower Child


View Profile
UQM 0.3, threads, linux, and pxa_250 CPU
« on: September 12, 2003, 12:01:27 am »

I'm currently trying to get UQM 0.3 running natively on my ipaq (I played v0.24 on it by forwarding the X display), but I've run into a snag.  Let me preface this post by saying that I'm running linux on my ipaq (http://www.handhelds.org), not pocket PC,  that all the SDL and vorbis libraries are available, and uqm and uqm-debug both compile.

What I'm getting is a signal problem with linux threads (based on the messages below).  Output from gdb:
Code:
Starting program: /mnt/ramfs/usr/bin/uqm-debug --res=320x240 -f --speechvol=0 -q=high --cscan=pc --music=pc --menu=pc --contentdir=/mnt/ramfs/usr/share/uqm/content --sound=none
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).
QDir::readDirEntries: Cannot read the directory: ../apps
SDL driver used: qtopia
SDL initialized.
Initializing Screen.
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
Set the resolution to: 320x240x16
WARNING: SetSemaphore did not return 0, this could be bad!
Initializing MixSDL mixer.
MixSDL using driver 'NoSound'

Program received signal SIG32, Real-time event 32.
0x40144dac in sigsuspend () from /lib/libc.so.6


The splash screen actually starts to display (looks great in 320x240), but it quickly seg faults if it's not run in gdb.

I originally thought this was a problem with incompatible libc's (between the machine that compiled the binary and the machine that was running it), but one of the maintainers of the version of linux for the ipaq wrote back:

Quote
This just means that gdb doesn't understand the signals used by LinuxThreads: it doesn't actually indicate any bug in your program.  You need to tell it to pass SIG32 on to the inferior without stopping.


I did some poking about in uqm-0.3/src/sc2code/libs/threads/, but I'm not too used to multi-thread programming.  Any tips on where to start?
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #1 on: September 12, 2003, 12:53:05 am »

The SIG32 problem isn't with uqm, it's with gdb and pthreads.
It seems that gdb can't handle it when /lib/libpthread.so is stripped.
The solution would be to compile a libpthread without stripping the libraries. (libpthreads is a part of libc)
Google for "SIG32" with "gdb" for more info.

Once you've got a new libpthread.so, debugging uqm should work fine.
(you might need to relink uqm)

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 Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #2 on: September 12, 2003, 12:58:50 am »

I'll try that.  Thanks for the quick reply meep-eep!

Edit:
Before I started mucking about with libc, I read through some of the pages that googling for gdb and SIG32 turned up.  Now I understand what the liinux-maintainer was trying to say:  Tell gdb to pass signal 32 without stopping, not uqm.
This let me get to the real seg fault. Unfortunately, gdb doesn't list the function call that elicits the problem.

Code:
(gdb) handle SIG32 noprint nostop pass
Signal        Stop      Print   Pass to program Description
SIG32         No        No      Yes             Real-time event 32
(gdb) file uqm-debug
Load new symbol table from "uqm-debug"? (y or n) y

Reading symbols from uqm-debug...done.
(gdb) show args
Argument list to give program being debugged when it is started is
   "--res=320x240 -f --speechvol=0 -q=high --cscan=pc --music=pc --menu=pc --contentdir=/mnt/ramfs/usr/share/uqm/content --sound=none".
(gdb) run
Starting program: /mnt/ramfs/usr/bin/uqm-debug --res=320x240 -f --speechvol=0 -q=high --cscan=pc --music=pc --menu=pc --contentdir=/mnt/ramfs/usr/share/uqm/content --sound=none
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).
QDir::readDirEntries: Cannot read the directory: ../apps
SDL driver used: qtopia
SDL initialized.
Initializing Screen.
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
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
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
       'arilou.shp' -- 301 bytes
       'arilou/ariicons.ani' -- 50 bytes
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
       'arilou/arimicon.ani' -- 46 bytes
       'arilou/aritext.txt' -- 407 bytes
QPainter::setPen: Will be reset by begin()
QPainter::setBrush: Will be reset by begin()
       'arilou/arilou.cod' -- 1 bytes

Program received signal SIGSEGV, Segmentation fault.
Cannot access memory at address 0x404e56ec


The memory address isn't static; other runs produce different addresses.  It looks like it's happening right before the chmmr content files get loaded if that's any help.  I'm using the content zip file since I'm limited on space.  I could stick the unzipped files on my much (much slower) CF card to test the unzipped data access, but I'll probably only try that as a last resort.
« Last Edit: September 12, 2003, 03:54:47 am by Culture20 » Logged
Culture20
Enlightened
*****
Offline Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #3 on: September 12, 2003, 07:41:04 am »

I just noticed the message "WARNING: SetSemaphore did not return 0, this could be bad!"  hiding in the output.  Tongue

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
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #4 on: September 12, 2003, 08:29:27 am »

That warning is innocent. We all get that when compiling in debug mode.

As for "telling gdb to pass SIG32", there's only one source that says that. There are a lot of others (much more if you search the newsgroups too) that say the problem is that gdb can't attach to the thread lib because it has no symbols.
Telling gdb to pass SIG32 would get rid of the symptom, but not of the problem.
Maybe it will allow you to debug uqm though.
Could you post a stack dump?

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 Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #5 on: September 13, 2003, 09:20:48 am »

I would if I knew how. I'm embarassed to say that I don't use gdb that often. Embarrassed

Here are my attempts to do a trace (editing out my attempts to read the in-gdb help menus):

Code:
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:
Code:
[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:

Quote
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.
Smiley
« Last Edit: September 13, 2003, 09:37:51 am by Culture20 » Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #6 on: September 13, 2003, 09:54:57 pm »

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.”
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #7 on: September 14, 2003, 06:42:25 am »

I've been told that we indeed never kill threads from the outside anymore. So it might just be another quirk of gdb because of pthreads having no debugging symbols.
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 Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #8 on: September 17, 2003, 07:45:51 am »

I found out that the machine I originally used to compile the binary has an unstripped version of libpthread.  Here's a run and a back-trace:
Code:

[New Thread 1024 (LWP 1760)]
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/guest/.uqm/save/.
Initializing SDL (pure).
SDL driver used: x11
SDL initialized.
Initializing Screen.
Set the resolution to: 320x240x32
WARNING: SetSemaphore did not return 0, this could be bad!
Initializing MixSDL mixer.
MixSDL using driver 'NoSound'
[New Thread 2049 (LWP 1761)]
[New Thread 1026 (LWP 1762)]
MixSDL mixer initialized.
   opened 'fake' at 44100 Hz 16 bit stereo, 4096 samples audio buffer
Initializing sound decoders.
Sound decoders initialized.
[New Thread 2051 (LWP 1763)]
0 joysticks were found.
Copying default key config file to user config dir.
[New Thread 3076 (LWP 1764)]
       'lbm/scclrtab.ct' -- 8722 bytes
We've loaded the Kernel
[New Thread 4101 (LWP 1765)]
       'lbm/title.ani' -- 19 bytes
[New Thread 5126 (LWP 1766)]
       '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.
[Switching to Thread 3076 (LWP 1764)]
0x000210dc in ReleaseCodeRes (CodeRef=0x35680065) at src/sc2code/dummy.c:360
360     src/sc2code/dummy.c: No such file or directory.
       in src/sc2code/dummy.c
(gdb) bt
#0  0x000210dc in ReleaseCodeRes (CodeRef=0x35680065)
   at src/sc2code/dummy.c:360
#1  0x0003ef80 in free_ship (StarShipPtr=0x63fa98, FreeBattleData=FALSE)
   at src/sc2code/loadship.c:169
#2  0x0003f14c in LoadMasterShipList () at src/sc2code/master.c:60
#3  0x00024130 in Introduction () at src/sc2code/fmv.c:94
#4  0x00056d70 in StartGame () at src/sc2code/restart.c:201
#5  0x0006d308 in Starcon2Main (blah=0x3b438c) at src/sc2code/starcon.c:895
#6  0x0011c394 in ThreadHelper (startInfo=0x60ef0c)
   at src/sc2code/libs/threads/thrcommon.c:196
#7  0x400792e4 in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0
#8  0x40079488 in SDL_KillThread () from /usr/lib/libSDL-1.2.so.0
#9  0x400ab65c in pthread_start_thread () from /lib/libpthread.so.0
#10 0x400ab6b0 in pthread_start_thread_event () from /lib/libpthread.so.0
#11 0x4020492c in clone () from /lib/libc.so.6
(gdb)


The following might help explain why the mem_unlock() doesn't work on my ipaq (weird memory addressing schemes), although I thought Macs did something similar... :
Quote
ARM Linux defaults to silently round the address to the appropriate alignment boundary.
http://www.handhelds.org/minihowto/porting-software.html
« Last Edit: September 17, 2003, 07:46:22 am by Culture20 » Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #9 on: September 18, 2003, 03:46:36 am »

For pthreads, as the linking is dynamically, what matters if the version of pthreads used on the machine where the program is running.

As for the memory alignment, this seems like a very good explanation. It doesn't work on 64 bits machines either yet. Though we'll get to that eventually.

« Last Edit: September 18, 2003, 03:47:17 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 Offline

Posts: 917


Thraddash Flower Child


View Profile
Re: UQM 0.3, threads, linux, and pxa_250 CPU
« Reply #10 on: September 20, 2003, 04:44:53 am »

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] Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!