intercept trap when running a 32bit binary

intercept trap when running a 32bit binary

[Robert Nagy]

Hi

I am trying to run 32bit binary Half Life dedicated server from Valve.

This is what happens (in a 32bit chroot or with 32bit libs installed:

./srcds_run: line 344: 13869 Segmentation fault      (core dumped)            
$HL_CMD                                                 
Cannot access memory at address 0xbfffb91c                                                                                                                            
/root/srcds/debug.cmds:4: Error in sourced command file:                                                                                                              
Cannot access memory at address 0xbfffb91c                                                                                                                            

I either get:                                                                                                                                                                      
Unexpected IA-32 intercept trap (Trap 46)                      
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f
Unexpected IA-32 intercept trap (Trap 46)                    
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f
Unexpected IA-32 intercept trap (Trap 46)
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f
Unexpected IA-32 intercept trap (Trap 46)
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f
Unexpected IA-32 intercept trap (Trap 46)
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f
Unexpected IA-32 intercept trap (Trap 46) 
  iip - 0x40c79b0b, ifa - 0x40f34000, isr - 0x11a6, iim - 0xc92a0f

or

Unexpected IA-32 intercept trap (Trap 46)
  iip - 0x401c683d, ifa - 0x4821b6af, isr - 0x600040000, iim - 0x0
Unexpected IA-32 intercept trap (Trap 46)
  iip - 0x401c683d, ifa - 0x4821b6af, isr - 0x600040000, iim - 0x0

The process gets a SIGSEGV there, from the kernel.

Is there anything i can do to make it work? Thanks

dmesg: http://www.pastebin.ca/589305

RE: intercept trap when running a 32bit binary

[Luck, Tony]

> I am trying to run 32bit binary Half Life dedicated server from Valve.
>
> This is what happens (in a 32bit chroot or with 32bit libs installed:
>
> ./srcds_run: line 344: 13869 Segmentation fault      (core dumped)

Do any x86 binaries work on this system?

Are you using ia32-el, or using h/w to execute (run "/etc/init.d/ia32el status"
to check).

If some x86 binaries work, then you could copy over an x86 gdb to
help debug this issue.

-Tony         

Re: intercept trap when running a 32bit binary

[Robert Nagy]

Yes, everything else works. A whole 32bit chroot works fine.
I guess when i enter the chroot i use h/w to execute the shell.

x86 gdb is installed in the chroot, but the backtrace is not quiet useful (for me).
more info:

Core was generated by `./srcds_i686 -game cstrike +map de_dust2 -maxplayers 12 -binary ./srcds_i686 -d'.                                                              
Program terminated with signal 11, Segmentation fault.                                                                                                                
#0  0x40c79b0b in global constructors keyed to date () from bin/engine_i686.so                                                                                        
#0  0x40c79b0b in global constructors keyed to date () from bin/engine_i686.so
No symbol table info available.
From        To          Syms Read   Shared Object Library
0x40023350  0x4003ded4  Yes         /lib/libm.so.6
0x40044c10  0x40045914  Yes         /lib/libdl.so.2
0x400611f0  0x4014079f  Yes         /lib/libc.so.6
0x40000790  0x400112cf  Yes         /lib/ld-linux.so.2
0x40176080  0x401913e0  Yes         bin/tier0_i486.so
0x401a81b0  0x401b0bb4  Yes         /lib/libpthread.so.0
0x401ff910  0x40208ff0  Yes         bin/vstdlib_i486.so
0x40246fb0  0x402a0cd0  Yes         bin/dedicated_i686.so
0x402d4610  0x402f6190  Yes         bin/soundemittersystem_i486.so
0x403530b0  0x403e31d0  Yes         bin/materialsystem_i486.so
0x40434330  0x40486800  Yes         bin/studiorender_i486.so
0x408c36a0  0x40a4e2b0  Yes         bin/vphysics_i486.so
0x40aba580  0x40af3180  Yes         bin/datacache_i486.so
0x40c6b5a0  0x40e8a3d0  Yes         bin/engine_i686.so
0x4103b410  0x41101040  Yes         bin/libsteamvalidateuseridtickets_i486.so
0x4114cb20  0x41158500  Yes         bin/steam_api_i486.so
Stack level 0, frame at 0xbfffb920:
 eip = 0x40c79b0b in global constructors keyed to date; saved eip End of Source crash report

On (25/06/07 16:24), Luck, Tony wrote:
> 
> Do any x86 binaries work on this system?
> 
> Are you using ia32-el, or using h/w to execute (run "/etc/init.d/ia32el status"
> to check).
> 
> If some x86 binaries work, then you could copy over an x86 gdb to
> help debug this issue.
> 
> -Tony         

RE: intercept trap when running a 32bit binary

[Luck, Tony]

> I guess when i enter the chroot i use h/w to execute the shell.

If ia32-el is installed and active, then it will keep on handling the
execution even inside the chroot.

> x86 gdb is installed in the chroot, but the backtrace is not quiet
useful (for me).
> more info:

Nothing useful there for me either ... though since the crash
looks like it is happening in some constructors, it is possible
that your program has some mistaken hard-coded assumptions that
the pagesize is 4K.  But that is just a really wild guess.

-Tony

RE: intercept trap when running a 32bit binary

[Yu, Fenghua]

>Program terminated with signal 11, Segmentation fault.

>#0  0x40c79b0b in global constructors keyed to date () from
>bin/engine_i686.so

>#0  0x40c79b0b in global constructors keyed to date () from
>bin/engine_i686.so
>No symbol table info available.
If you can build code with symbol info, you can map the failure point to
source code and analyze the source code.

Thanks.

-Fenghua

Re: intercept trap when running a 32bit binary

[Robert Nagy]

I would have done that already of course, but the source code
is not available. This is a binary only release from http://www.valvesoftware.com/

On (25/06/07 17:04), Yu, Fenghua wrote:
> >Program terminated with signal 11, Segmentation fault.
> 
> >#0  0x40c79b0b in global constructors keyed to date () from
> >bin/engine_i686.so
> 
> >#0  0x40c79b0b in global constructors keyed to date () from
> >bin/engine_i686.so
> >No symbol table info available.
> If you can build code with symbol info, you can map the failure point to
> source code and analyze the source code.
> 
> Thanks.
> 
> -Fenghua

Re: intercept trap when running a 32bit binary

[Robert Nagy]

I've set the pagesize to 4096 in the kernel but that did not
solve the problem.

On (25/06/07 16:45), Luck, Tony wrote:
> Nothing useful there for me either ... though since the crash
> looks like it is happening in some constructors, it is possible
> that your program has some mistaken hard-coded assumptions that
> the pagesize is 4K.  But that is just a really wild guess.
> 
> -Tony

RE: intercept trap when running a 32bit binary

[Luck, Tony]

> I've set the pagesize to 4096 in the kernel but that did not
> solve the problem.

Bother.  Another thing to try might be to use strace (the x86 version
in your chroot subtree) to see how far the program gets before it
dies.  If you have a native x86 system to compare this strace output
with what is supposed to happen, that would be even better.

-Tony

Re: intercept trap when running a 32bit binary

[Robert Nagy]

On (26/06/07 09:30), Luck, Tony wrote:
> Bother.  Another thing to try might be to use strace (the x86 version
> in your chroot subtree) to see how far the program gets before it
> dies.  If you have a native x86 system to compare this strace output
> with what is supposed to happen, that would be even better.

Hi

Here is the output http://humppa.hu/typescript

This is the only linux system i have, but I can provide
almost the same output running the same program on OpenBSD
with the linux binary compat.

RE: intercept trap when running a 32bit binary

[Luck, Tony]

> Here is the output http://humppa.hu/typescript

Nothing stands out there as totally off.  The program did open
and read /proc/cpuinfo shortly before it died, so it might have
found something that it didn't like in there (though it also read
it just after startup without apparent ill effects).

Then at the very end it failed to open "steam.cfg" ... perhaps
that was what it didn't like?

-Tony

Re: intercept trap when running a 32bit binary

[Robert Nagy]

Unfortunately having steam.cfg is optional and it
does not change anything.

On (26/06/07 12:13), Luck, Tony wrote:
> > Here is the output http://humppa.hu/typescript
> 
> Nothing stands out there as totally off.  The program did open
> and read /proc/cpuinfo shortly before it died, so it might have
> found something that it didn't like in there (though it also read
> it just after startup without apparent ill effects).
> 
> Then at the very end it failed to open "steam.cfg" ... perhaps
> that was what it didn't like?
> 
> -Tony

Re: intercept trap when running a 32bit binary

[Robert Nagy]

Unfortunately having steam.cfg is optional and it
does not change anything.

On (26/06/07 12:13), Luck, Tony wrote:
> > Here is the output http://humppa.hu/typescript
> 
> Nothing stands out there as totally off.  The program did open
> and read /proc/cpuinfo shortly before it died, so it might have
> found something that it didn't like in there (though it also read
> it just after startup without apparent ill effects).
> 
> Then at the very end it failed to open "steam.cfg" ... perhaps
> that was what it didn't like?
> 
> -Tony