Debugging reboot with Linux emulation

[Alexander Leidinger]

Quoting "Kostik Belousov" <kostikbel at gmail.com> (from Wed, 13 Aug 2008  
17:10:59 +0300):

> On Wed, Aug 13, 2008 at 04:03:53PM +0200, Alexander Leidinger wrote:
>> Quoting "Kostik Belousov" <kostikbel at gmail.com> (from Wed, 13 Aug 2008
>> 14:54:13 +0300):
>>
>> >On Wed, Aug 13, 2008 at 01:28:22PM +0200, Alexander Leidinger wrote:
>> >>Quoting "Nate Eldredge" <neldredge at math.ucsd.edu> (from Tue, 12 Aug
>> >>2008 23:52:35 -0700 (PDT)):
>> >>
>> >>>Hi folks,
>> >>>
>> >>>I recently tried to run a Linux binary of Maple (commercial math
>> >>>software) on my FreeBSD 7.0-RELEASE/amd64 box, and the machine
>> >>>rebooted.  I tried it again while watching the console, and no panic
>> >>>message appeared to be produced.  Does anyone have any ideas on how
>> >>>to debug problems of this nature?  I realize I may not be able to
>> >>>get Maple to work, but in any case the system should not die like
>> >>>this, so I can at least try to fix that bug.
>> >>>
>> >>>Incidentally, is it possible to run kdb with a USB keyboard?
>> >>>Hitting Ctrl-Alt-Esc gives me the kdb prompt, but I can't type, so I
>> >>>can do nothing except hit the power button.  I do have
>> >>>hint.atkbd.0.flags="0x1" in /boot/device.hints.  Unfortunately I
>> >>>don't have a PS/2 keyboard on hand, though I can try and get a hold
>> >>>of one if all else fails.
>> >>
>> >>A guess out of my cristallball:
>> >>That's one of the cases which happen if you run a linux program
>> >>without branding it as a linux program first. People tend to think it
>> >>is not needed, but in some rare circumstances it just causes what you
>> >>see, a reboot. So go and identify all binaries (IMPORTANT: but not the
>> >>libraries!), e.g. with the file(1), and use "brandelf -t Linux" on
>> >>those programs.
>> >
>> >That would be an enormous local hole, assuming an native FreeBSD binary
>> >may cause system crash. I actually doubt that non-branded elf binary
>> >ever start, due to unsatisfied dynamic dependencies.
>>
>> You see this behavior only for static binaries. In the non-branded
>> case the image activator takes the FreeBSD image and unfortunately
>> there's a common syscall in linux which matches the syscall number in
>> FreeBSD which causes the reboot (IIRC reboot syscall, do we have
>> something like this?). It's not a system crash (kernel panic), it's a
>> real reboot. AFAIR this also only works if you run the program as
>> root. So...
>
> Then, the issue of mixing our reboot(2)/linux fcntl(2) is irrelevant.
> The original reporter said that system "just rebooted", and I believe
> that filesystems where not synced and not unmounted properly. Our
> reboot(2) does not have flag combination that could cause such
> behaviour, I think.
>
> Also, I doubt that the program being run is statically linked or
> run by root. Confirmation ?

I will not be surprised if it is statically linked and run by root.  
I've seen enough such cases with commercial software and users using  
it, that my cristalball caused me to send my first reply to the problem.

> Overall, this looks like a nasty bug, hopefully in the linuxolator.

The linuxulator is not involved, as there's no branding it is not  
invoked. The same will happen if the linxulator is not in the kernel.

Bye,
Alexander.

-- 
If value corrupts then absolute value corrupts absolutely.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137