[maemo-developers] Processing a core dump on armel platform - proc entry gone

From: Eero Tamminen eero.tamminen at nokia.com
Date: Thu Oct 9 11:44:30 EEST 2008
Hi,

ext Marcus Förster wrote:
> I contact you as the maintainer of sp-rich-core.
 >
> We're doing an embedded linux project, and we're using a few maemo packages:
>  
> dbus                   1.0.2-0osso12
> dbus-1-utils           1.0.2-0osso12
> libdbus-1-3            1.0.2-0osso12
> libdbus-glib-1-2       0.74-0osso2
> libglib2.0-0           2.12.12-1osso9
>  
> We're not using sp-rich-core, but we're using a similar approach to
> processing core files as sp-rich-core. The filter program is a C++ binary
> executable though.
>  
> Now we're facing a problem, and I hope you can shed a bit of light on this.
>  
> Under certain conditions, the /proc entry of the process that dumped core is
> already gone by the time the core filter program is invoked. This happens
> reliably if the dumping program creates a D-Bus proxy using the GLib
> bindings, starts a main loop and runs for some time (less than a second).
> Without any one of these conditions, the /proc entry is still there when the
> core filter is invoked. It is not necessary to do anything with the D-Bus
> proxy to reproduce this.

Does the same happen also with sp-rich-core with regular maemo kernel
on the N8x0 device?  If yes, please file a bug about this to
bugs.maemo.org & attach your test-code there.


> Did you have any similar problems when implementing sp-rich-core, or do you
> have any idea what the cause to this problem might be?

Not that I know of, but we don't have D-BUS services that crash
in <1 sec... :-)

If you cannot reproduce this on our releases, you could look at
the related code on the kernel side.  We had some modifications
there, but I don't remember whether all of them were accepted
upstream (I would expect so though).

(And for debugging the issue, just run the code under Gdb...)


	- Eero

More information about the maemo-developers mailing list