Just to collect more puzzle pieces, I got three replies by now about my "which driver" question, and these three are all using the proprietary NVIDIA driver. It might be just pure luck with a sample size of three, of course, so I asked whether anyone who got this crash has a different card/driver.
(In reply to comment #3)
> I meant, which extensions are these applications actually using? I'm hoping to
> pin the blame on a client-side extension library rather than libX11 itself. ;-)
> The list of loaded libraries from GDB would be a start.
We routinely collect /proc/<pid>/maps in crash reports, they all have a "ProcMaps.txt" attachment. However, this just says which libraries the program dynamically links against, not which extensions it's actually using, right?
Is there a better way to see which extensions a program is currently using? Some command that I could ask the bug reporters to run? We could even add that to our standard Apport hooks, so that it's collected for all crash reports.
> Is there some Launchpad way to download all the attachments from all the public duplicate bugs at once?
Bryce Harrington (CC added) has put together a lot of scripts for these purposes (X.org bug triaging). Bryce, do you have a script like that?
Anyway, it's really easy using the Python API, so for this particular purpose I wrote a quick hack which downloads a particular attachment name from a bug and all its duplicates and dumps them to stdout:
Just to collect more puzzle pieces, I got three replies by now about my "which driver" question, and these three are all using the proprietary NVIDIA driver. It might be just pure luck with a sample size of three, of course, so I asked whether anyone who got this crash has a different card/driver.
(In reply to comment #3)
> I meant, which extensions are these applications actually using? I'm hoping to
> pin the blame on a client-side extension library rather than libX11 itself. ;-)
> The list of loaded libraries from GDB would be a start.
We routinely collect /proc/<pid>/maps in crash reports, they all have a "ProcMaps.txt" attachment. However, this just says which libraries the program dynamically links against, not which extensions it's actually using, right?
Is there a better way to see which extensions a program is currently using? Some command that I could ask the bug reporters to run? We could even add that to our standard Apport hooks, so that it's collected for all crash reports.
> Is there some Launchpad way to download all the attachments from all the public duplicate bugs at once?
Bryce Harrington (CC added) has put together a lot of scripts for these purposes (X.org bug triaging). Bryce, do you have a script like that?
Anyway, it's really easy using the Python API, so for this particular purpose I wrote a quick hack which downloads a particular attachment name from a bug and all its duplicates and dumps them to stdout:
$ ./cat-bugattach ment.py 507062 ProcMaps.txt libgdk- x11-2.0. so.0.1902. 0 firefox- 3.0.7/firefox
---- 507062 ---
00110000-001ae000 r-xp 00000000 08:05 526394 /usr/lib/
[...]
---- 340441 ---
00400000-00408000 r-xp 00000000 09:01 94936 /usr/lib/
[...]
and so on. The script takes the master bug number and an attachment name, I put it on http:// people. canonical. com/~pitti/ scripts/ cat-bugattachme nt.py for now.
When I do some simple post-processing of the output of above command (which I directed into file "out") I get this:
$ grep lib/libX out | awk '{print $6}' | sort -u libX11. so.6.2. 0 libX11. so.6.3. 0 libXau. so.6.0. 0 libXcomposite. so.1.0. 0 libXcursor. so.1.0. 2 libXdamage. so.1.1. 0 libXdmcp. so.6.0. 0 libXext. so.6.4. 0 libXfixes. so.3.1. 0 libXft. so.2.1. 13 libXinerama. so.1.0. 0 libXi.so. 6.0.0 libXi.so. 6.1.0 libXmu. so.6.2. 0 libXrandr. so.2.2. 0 libXrender. so.1.3. 0 libXRes. so.1.0. 0 libXss. so.1.0. 0 libXt.so. 6.0.0 libXtst. so.6.1. 0 libXxf86misc. so.1.1. 0 libXxf86vm. so.1.0. 0
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
Not sure how helpful that actually is, though, since those are still a fair number of extensions.
Thank you!