Bug 3149 - ltrace-ing uClibc bme_RX-34 on Glibc system leads to segfault and reboot
: ltrace-ing uClibc bme_RX-34 on Glibc system leads to segfault and reboot
Status: RESOLVED INVALID
Product: Development platform
Tools
: 4.0
: All Maemo
: Low normal (vote)
: ---
Assigned To: integration
: sdk-tools-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2008-05-11 20:50 UTC by Nick Loeve
Modified: 2008-07-02 17:19 UTC (History)
2 users (show)

See Also:


Attachments
installed packages (170.19 KB, text/plain)
2008-05-11 20:52 UTC, Nick Loeve
Details
bme core dump (232.00 KB, application/octet-stream)
2008-05-11 20:52 UTC, Nick Loeve
Details
ltrace core dump (404.00 KB, application/octet-stream)
2008-05-11 20:53 UTC, Nick Loeve
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Nick Loeve (reporter) 2008-05-11 20:50:33 UTC
SOFTWARE VERSION: 

2.2007.51-3

STEPS TO REPRODUCE THE PROBLEM:

Nokia-N800-51-3:/# ltrace -p PID_OF_BME

then plug in the charger 


EXPECTED OUTCOME:

system tracing to continue

ACTUAL OUTCOME:

segmentation fault and nokia logo flashes up and the device make a slight
popping sound, then reboots normally.

REPRODUCIBILITY:
(always/sometimes/once)
always

EXTRA SOFTWARE INSTALLED:

Newish install with some dev tools installed. Package list attached.

OTHER COMMENTS:

I have attached the core dumps of the processes involved

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14)
Gecko/20080501 Firefox/2.0.0.14
Comment 1 Nick Loeve (reporter) 2008-05-11 20:52:13 UTC
Created an attachment (id=762) [details]
installed packages
Comment 2 Nick Loeve (reporter) 2008-05-11 20:52:44 UTC
Created an attachment (id=763) [details]
bme core dump
Comment 3 Nick Loeve (reporter) 2008-05-11 20:53:07 UTC
Created an attachment (id=764) [details]
ltrace core dump
Comment 4 Eero Tamminen nokia 2008-05-15 16:26:34 UTC
> STEPS TO REPRODUCE THE PROBLEM:
> - Nokia-N800-51-3:/# ltrace -p PID_OF_BME
> - then plug in the charger 
>
> ACTUAL OUTCOME:
> - segmentation fault ... reboots

BME is using uClibc and started from initfs before rootfs pivot_root.
Rootfs uses Glibc, so ltrace is naturally confused.  Ltrace ARM support
for library tracing is not complete (and ltrace has bugs even on x86)
so there might be also other issues.

Diablo is going to have some further ltrace ARM fixes, but I doubt you would
still be able to do dynamically linked uClibc binary tracing using Glibc
system.  You might try building uClibc version of ltrace, copying it to
initfs (after removing test-server to make room) and then chroot there
(with /proc etc mounts) before running ltrace.

Plain system call tracing ("ltrace -S" or "strace") should work for bme though.
Comment 5 Nick Loeve (reporter) 2008-05-15 17:02:11 UTC
(In reply to comment #4)
> > STEPS TO REPRODUCE THE PROBLEM:
> > - Nokia-N800-51-3:/# ltrace -p PID_OF_BME
> > - then plug in the charger 
> >
> > ACTUAL OUTCOME:
> > - segmentation fault ... reboots
> 
> BME is using uClibc and started from initfs before rootfs pivot_root.
> Rootfs uses Glibc, so ltrace is naturally confused.  Ltrace ARM support
> for library tracing is not complete (and ltrace has bugs even on x86)
> so there might be also other issues.

Ah of course!

> 
> Diablo is going to have some further ltrace ARM fixes, but I doubt you would
> still be able to do dynamically linked uClibc binary tracing using Glibc
> system.  You might try building uClibc version of ltrace, copying it to
> initfs (after removing test-server to make room) and then chroot there
> (with /proc etc mounts) before running ltrace.

Ok, i might try that out

> 
> Plain system call tracing ("ltrace -S" or "strace") should work for bme though.
> 

Yes system call tracing is working without issue.
Comment 6 Frantisek Dufka maemo.org 2008-06-10 10:53:10 UTC
(In reply to comment #5)
> 
> Yes system call tracing is working without issue.
>
Just FYI, there are issues with some system calls missing or incorrect so don't
believe it blindly, at least this patch is not applied to diablo strace so
socket calls are missing
http://marc.info/?l=strace&m=120126455227098&w=2
this is useful if you want to strace dsmetest or anything else talking to dsme.

There was also another patch that fixed completely wrong syscalls
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg171554.html
but I think this one is in diablo strace already (not sure, have my own patched
strace).
Comment 7 Eero Tamminen nokia 2008-06-10 11:27:09 UTC
This is tools, not BME issue -> moving

(We're not going to provide uClibc version of strace/ltrace as our
Debian stuff is for rootfs/Glibc, but you have the sources and can
report issues if the tools don't work when built with uClibc.)


(In reply to comment #6)
> Just FYI, there are issues with some system calls missing or incorrect so
> don't believe it blindly, at least this patch is not applied to diablo
> strace so socket calls are missing
> http://marc.info/?l=strace&m=120126455227098&w=2
> this is useful if you want to strace dsmetest or anything else talking
> to dsme.

Diablo strace should support -e trace=network syscalls...?
Comment 8 Frantisek Dufka maemo.org 2008-06-10 12:01:53 UTC
(In reply to comment #6)
> There was also another patch that fixed completely wrong syscalls
> http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg171554.html
> but I think this one is in diablo strace already (not sure, have my own patched
> strace).

First sorry for confusion, I should say chinook everywhere, not diablo. Also
both patches seems to be not in chinook strace, it is fixed in upstream 4.5.15
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360154 and when stracing
dsmetest on N810 I see bogus mq_notify call instead of SYS_281 (with this
patch) or correct 'socket' call with second patch.

(In reply to comment #7)
> Diablo strace should support -e trace=network syscalls...?
>
sorry if this is due to my Chinook/Diablo confusion, I don't know about Diablo.
Also not sure what -e trace=network does but that patch is useful for seeing
correct syscall names and arguments of socket calls (socket, bind, connect, ..)
like the PFLOCAL/PF_UNIX ones used by dsme
Comment 9 Frantisek Dufka maemo.org 2008-06-10 12:14:41 UTC
(In reply to comment #5)
> 
> Yes system call tracing is working without issue.
> 
Just tried ltrace -S too and it is OK, it correctly shows SYS_socket,
SYS_connect etc. Only strace is buggy so sorry yet again for muddying this
ltrace bug report with strace-only bugs. Should I create bug report separately
for strace or can we just abuse this bug and change summary to something like
'strace shows wrong syscalls'?
Comment 10 Nick Loeve (reporter) 2008-06-10 12:34:51 UTC
(In reply to comment #9)
> (In reply to comment #5)
> > 
> > Yes system call tracing is working without issue.
> > 
> Just tried ltrace -S too and it is OK, it correctly shows SYS_socket,
> SYS_connect etc. Only strace is buggy so sorry yet again for muddying this
> ltrace bug report with strace-only bugs. Should I create bug report separately
> for strace or can we just abuse this bug and change summary to something like
> 'strace shows wrong syscalls'?
> 

Hi Frantisek,

I reckon a separate bug would be useful, as this original bug report has
gleaned some useful information, and the issues and patches you have
highlighted shouldn't be lost either.

Cheers
Comment 11 Frantisek Dufka maemo.org 2008-06-10 13:41:21 UTC
(In reply to comment #10)
> I reckon a separate bug would be useful, as this original bug report has
> gleaned some useful information, and the issues and patches you have
> highlighted shouldn't be lost either.

OK, bug #3232
Comment 12 Juha Kallioinen nokia 2008-07-02 14:04:43 UTC
How should this bug be resolved then? The original report is a bit invalid with
the uclibc/glibc confusion and the rest goes on to talk about other things.
Comment 13 Eero Tamminen nokia 2008-07-02 15:43:46 UTC
I'm marking this as invalid.

If one wants to ltrace uClibc binaries, one needs to build uClibc ltrace
(preferably from Diablo ltrace sources, they have additional fixes).

I have no idea whether ltrace builds with our uClibc though, if not,
that would be a separate bug.
Comment 14 Frantisek Dufka maemo.org 2008-07-02 16:05:50 UTC
Ok, this is invalid so I will pollute this bug again since it is related.
Building ltrace with uclibc is nice idea but where does one get uclibc
toolchain compatible with N8x0 initfs?

page http://maemo.org/community/wiki/os2007hackereditionarchives/ mentions
scratchbox-toolchain-cs2005q3.2-uclibc-arm-eabi_0.9.8.5-3_i386.deb but where it
is? I searched scratchbox site and did not find it.

I have toolchain for 770 initfs but for N8x0 initfs (for bootmenu) I curently
need to build stuff statically. I tried few uclibc toolchains from scratchbox
site but got errors when running the command. I guess final binary needs to
link to uclibc 0.9.28 and use EABI which is not common combination.
Comment 15 Frantisek Dufka maemo.org 2008-07-02 16:45:32 UTC
created separate bug #3373 for this
Comment 16 Nick Loeve (reporter) 2008-07-02 17:19:44 UTC
Also to note is that when bme segfaulted and the device rebooted it made a loud
popping noise, which i guess is not that great.

I understand the glibc/uclibc part now... but maybe we should add a warning to
the tools page on maemo that using the supplied ltrace to trace initfs binaries
may not be very good for the device.