[Dev] Tizen 3.0 : Optimizing applications launch time

Stéphane Desneux stephane.desneux at eurogiciel.fr
Mon Oct 21 15:43:12 GMT 2013

On 21/10/2013 16:39, Jussi Laako wrote:
> On 21.10.2013 13:51, Stéphane Desneux wrote:
>> ABRT seems to be able to download the debuginfos on the fly to produce
>> more meaningfull dumps. But for Tizen it's probably not a good idea as
>> we don't want to fill the user device with debug files !
> It should be only enabled in developer mode / engineering images, not
> for final products.

Yes, that's what I had in mind too.

>> I wonder if the crashreporter can produce correct reports with partially
>> stripped binaries: I mean we could strip the .debug_info section
>> (responsible for the extra weight) but keep the other symbols to have
>> meaningful backtraces. i.e running 'strip --strip-debug' instead of
>> 'strip --strip-all'.
> Just as with normal core dumps, crashreporter should only report the
> address info, it shouldn't try to resolve symbols. And then when
> analyzing the crash you can have the symbol information available. This
> is normal way on other platforms too.

If the crash reporter is for developer mode / engineering mode, we can 
keep things simple by downloading debuginfos and resolving the symbols 
on the crashed host (or alternatively, have an image with all/partial 
debuginfos already present and debug the core dumps without any reporter !)

But if the end user can send crash reports, I agree with you:
- core dumps can't be sent as they may contain secure/private information
- downloading/installing (or pre-installing) debuginfos on a user device 
to resolve symbols is not very efficient.
=> the only way is to push the stack trace (with addresses) and some 
related infos (package versions, device release/update info etc.)

Please note that it'll get more complex on the server side after a while 
when multiple versions of the same lib have been shipped (multiple 
Upon receipt of a crash report, you have to peek the right debuginfos: 
this is closely related to how releases and upgrades are done. This is 
only possible with an appropriate coordination/organization (and this 
gets off-topic :-))

Thanks for your ideas.

Stéphane Desneux
Intel OTC - Vannes/FR

More information about the Dev mailing list