The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
November 30, 2021, 07:32:58 pm
Home Help Search Login Register
News: Paul & Fred have reached a settlement with Stardock!

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  UQM on Eee PC
« previous next »
Pages: 1 [2] Print
Author Topic: UQM on Eee PC  (Read 4681 times)
Novus
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1938


Fot or not?


View Profile
Re: UQM on Eee PC
« Reply #15 on: July 11, 2009, 11:18:10 am »


This feature already exists in the current SVN version. Grin


I dot think I've ever seen Novus use a smiley face before. You in a particularly chipper mood this week Novus?

You haven't been paying attention. Wink Still, the summer sun does brighten up your day, doesn't it? Cheesy
Logged

RTFM = Read the fine manual.
RTTFAQ = Read the Ur-Quan Masters Technical FAQ.
v.v.b.
Zebranky food
*
Offline Offline

Posts: 13



View Profile
Re: UQM on Eee PC
« Reply #16 on: July 26, 2009, 07:56:11 am »

It looks like you are using pthread for threading library. Please try using SDL (./build.sh uqm config, item 10) and see if that works out.

 I've always use SDL AFAIR...

 Output of 'thread apply all bt':
Code:
...................... it's the end of 'main' log:....................................
'lbm/boosml.ani' -- 194 bytes
[Thread 0x7fffee138950 (LWP 4397) exited]
[New Thread 0x7fffee138950 (LWP 4398)]
[Thread 0x7fffee138950 (LWP 4398) exited]
[New Thread 0x7ffff2320950 (LWP 4399)]
Warning: Can't open 'lbm/mainmenu.ogg'
'lbm/newgame.ani' -- 177 bytes
Warning: Can't open 'lbm/mainmenu.ogg'
'lbm/newgame.ani' -- 177 bytes
[Thread 0x7ffff2320950 (LWP 4399) exited]
[New Thread 0x7ffff2320950 (LWP 4400)]
[New Thread 0x7fffee138950 (LWP 4401)]
[Thread 0x7fffee138950 (LWP 4401) exited]
[New Thread 0x7fffee138950 (LWP 4402)]
[Thread 0x7ffff2320950 (LWP 4400) exited]
Thread 'Unknown (probably renderer)' blocking on 'DCQ'
Thread 'Unknown (probably renderer)' blocking on 'DCQ'

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2f5d950 (LWP 4390)]
0x00000037faa2e1d7 in ?? ()
(gdb) thread apply all bt

Thread 14 (Thread 0x7fffee138950 (LWP 4402)):
#0  0x00000037f3e0e851 in nanosleep () from /lib64/libpthread.so.0
#1  0x00000037ff05a4d4 in SDL_Delay () from /usr/lib64/libSDL-1.2.so.0
#2  0x000000000046a88f in SDL_EnableUNICODE ()
#3  0x00000000004b08db in SDL_EnableUNICODE ()
#4  0x00000037ff011017 in ?? () from /usr/lib64/libSDL-1.2.so.0
#5  0x00000037ff056fc9 in ?? () from /usr/lib64/libSDL-1.2.so.0
#6  0x00000037f3e073da in start_thread () from /lib64/libpthread.so.0
#7  0x00000037f32e62bd in clone () from /lib64/libc.so.6

Thread 7 (Thread 0x7fffecd36950 (LWP 4395)):
#0  0x00000037f3e0e851 in nanosleep () from /lib64/libpthread.so.0
#1  0x00000037ff05a4d4 in SDL_Delay () from /usr/lib64/libSDL-1.2.so.0
#2  0x00000000004a630c in SDL_EnableUNICODE ()
#3  0x00000000004b08db in SDL_EnableUNICODE ()
#4  0x00000037ff011017 in ?? () from /usr/lib64/libSDL-1.2.so.0
#5  0x00000037ff056fc9 in ?? () from /usr/lib64/libSDL-1.2.so.0
#6  0x00000037f3e073da in start_thread () from /lib64/libpthread.so.0
#7  0x00000037f32e62bd in clone () from /lib64/libc.so.6

Thread 6 (Thread 0x7fffed737950 (LWP 4394)):
#0  0x00000037f32dc886 in poll () from /lib64/libc.so.6
#1  0x0000003803852f96 in ?? () from /lib64/libasound.so.2
#2  0x0000003803853357 in ?? () from /lib64/libasound.so.2
---Type <return> to continue, or q <return> to quit---
#3  0x000000380385ea6a in snd_pcm_mmap_writei () from /lib64/libasound.so.2
#4  0x00000037ff036afd in ?? () from /usr/lib64/libSDL-1.2.so.0
#5  0x00000037ff0096de in ?? () from /usr/lib64/libSDL-1.2.so.0
#6  0x00000037ff011017 in ?? () from /usr/lib64/libSDL-1.2.so.0
#7  0x00000037ff056fc9 in ?? () from /usr/lib64/libSDL-1.2.so.0
#8  0x00000037f3e073da in start_thread () from /lib64/libpthread.so.0
#9  0x00000037f32e62bd in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7ffff2f5d950 (LWP 4390)):
#0  0x00000037faa2e1d7 in ?? ()
#1  0x00000037f3e07479 in start_thread () from /lib64/libpthread.so.0
#2  0x00000037f32e62bd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7ffff7fce730 (LWP 4387)):
#0  0x00000037f3e0db14 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00000037f3e091cb in _L_lock_312 () from /lib64/libpthread.so.0
#2  0x00000037f3e08bd1 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00000037ff05729e in SDL_mutexP () from /usr/lib64/libSDL-1.2.so.0
#4  0x00000000004b074b in SDL_EnableUNICODE ()
#5  0x00000000004a243f in SDL_EnableUNICODE ()
#6  0x00000000004a2721 in SDL_EnableUNICODE ()
#7  0x0000000000475872 in SDL_EnableUNICODE ()
#8  0x00000000004070e5 in SDL_EnableUNICODE ()
#9  0x00000037f321e576 in __libc_start_main () from /lib64/libc.so.6
#10 0x00000000004055f9 in SDL_EnableUNICODE ()
---Type <return> to continue, or q <return> to quit---
#11 0x00007fffffffe658 in ?? ()
#12 0x000000000000001c in ?? ()
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffe8a0 in ?? ()
#15 0x0000000000000000 in ?? ()
#0  0x00000037faa2e1d7 in ?? ()


 Hope it helps...
Logged
fossil
Core Team
Frungy champion
*****
Offline Offline

Gender: Male
Posts: 94



View Profile
Re: UQM on Eee PC
« Reply #17 on: July 26, 2009, 06:57:47 pm »

I don't know why the code ends up at a location that does not belong to any .so (at least according to gdb). Let's look at the process maps. Please make two map dumps: one while the game is running and one when it segfaults, and post them here. Assuming you are using a debug build and the executable is uqm-debug, dump the maps like so:
Code:
cat /proc/`pidof uqm-debug`/maps
(probably better to redirect the output to some file)
You will need to do the dumps in a separate terminal window. Of course, the game has to be under gdb when it segfaults, or you'll be dumping a map of a process that does not exist anymore  Wink
« Last Edit: July 26, 2009, 06:59:40 pm by fossil » Logged
v.v.b.
Zebranky food
*
Offline Offline

Posts: 13



View Profile
Re: UQM on Eee PC
« Reply #18 on: July 26, 2009, 08:14:28 pm »

Assuming you are using a debug build and the executable is uqm-debug

 Oh! Terribly sorry! I've start gdb with simply uqm! Many apologies!
 But now when I start gdb uqm-debug and 'start' after it, I get:
Code:
(gdb) start
Breakpoint 1 at 0x40663c: file src/starcon2.c, line 148.
Starting program: /home/vvb/rpmbuild/SOURCES/sc2/sc2/uqm-debug
[Thread debugging using libthread_db enabled]

[1]+  Stopped                 gdb uqm-debug

 and after 'run' I get:
Code:
(gdb) run
Starting program: /home/vvb/rpmbuild/SOURCES/sc2/sc2/uqm-debug
[Thread debugging using libthread_db enabled]

[2]+  Stopped                 gdb uqm-debug
Logged
fossil
Core Team
Frungy champion
*****
Offline Offline

Gender: Male
Posts: 94



View Profile
Re: UQM on Eee PC
« Reply #19 on: July 27, 2009, 12:58:33 am »

Don't do start, just do run from the get go.
Logged
v.v.b.
Zebranky food
*
Offline Offline

Posts: 13



View Profile
Re: UQM on Eee PC
« Reply #20 on: July 27, 2009, 04:43:22 pm »

As I said, I can't run it.
After 'run' command gdb says:
Code:
(gdb) run
Starting program: /home/vvb/rpmbuild/SOURCES/sc2/sc2/uqm-debug
[Thread debugging using libthread_db enabled]

[1]+  Stopped                 gdb uqm-debug
And quit to console...
Logged
fossil
Core Team
Frungy champion
*****
Offline Offline

Gender: Male
Posts: 94



View Profile
Re: UQM on Eee PC
« Reply #21 on: July 27, 2009, 04:55:46 pm »

I don't know why this happens.  Undecided  Perhaps someone else can tell why. You may need to rebuild the uqm-debug executable, especially if you recently upgraded the OS.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: UQM on Eee PC
« Reply #22 on: July 27, 2009, 05:45:16 pm »

That sounds like a problem with gdb itself. I suspect that the suspend signal which is sent to the child somehow ends up at the gdb process itself. Are you running a recent gdb and kernel?
What happens if you continue gdb by typing 'fg' on your shell prompt?
Something else you could try is to run uqm, and then attach gdb to the running process:
Code:
gdb uqm-debug `pidof uqm-debug`
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Pages: 1 [2] 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!