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
releases/upgrades).
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
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
