[Webkit-unassigned] [Bug 128928] Improve GDB backtrace generation for GTK/EFL
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Dec 23 06:42:51 PST 2015
--- Comment #7 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to comment #6)
> coredumpctl is not useful for bots -- anything that makes coredumps display
> in the web interface would be a great solution there -- but for humans
> running tests manually, we should try to figure out a solution that doesn't
> require editing core_pattern to disable it.
Humans running tests can already match a coredump with a test name. Is a matter of running only one test at a time and picking the last coredump.
The main use case here is for the bots. The bots runs thousands of tests in parallel, and they need a way to match the coredump with the test name. Otherwise is not possible to show the backtrace/crash log on the results page that the bot published.
For example: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20%28Tests%29/r189464%20%2810899%29/results.html
Notice the empty crash logs on that html page published by the bot? That's what we are trying to fix here.
> (In reply to comment #5)
> > I guess that would require the users to run systemd. This can be problematic
> > on the bots (they run on unprivileged containers, and systemd don't plays
> > nice there)
> Huh, I didn't realize that. I thought all Linux except Gentoo was using
> systemd nowadays (certainly it's installed on the bots I used yesterday),
> and that it was designed to handle unprivileged containers nicely -- that's
> the whole point of machinectl, right? but I've hardly used containers myself.
Well, Ubuntu is still using upstart (the switch to systemd still didn't happened.. I guess that by 16.04 maybe).
And with unprivileged containers I mean LXC namespace based containers, and systemd is not running correctly inside there.
I think i read that in the latest releases of systemd this was somehow fixed, but I didn't tested it. So I remain cautious about the possibility of using something like coredumpctl inside a LXC namespace based container until I test it and see it working.
> > So... the main question.... is coredumpctl able to get and print the
> > environ variables that a program had defined when it crashed for a given
> > coredump? If is not, I don't think it will be of any help here.
> Hm, I don't think so. You can match on an awful lot, anything listed in
> systemd.journal-fields(7), but not environment variables. It'd be easy to
> add though, since it has access to /proc/$pid/environ as you say, we'd just
> need to make it save the environment as a journal field. This is how the
> abrt coredumpctl integration was written -- abrt needed more info on the
> coredumps, so they modified coredumpctl to save it in journal fields. But
> that is a lot more work....
If you are interested on adding this to systemd please go ahead..
But take into account that because of the release cycles of the distributions, the time it will take to reach the systemd used by all our developers (debian/ubuntu/fedora/etc) will be measured in years.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-unassigned