https://bugs.freedesktop.org/show_bug.cgi?id=101998
--- Comment #35 from Meik Neubauer <t...@meikneubauer.de> ---
(In reply to Michel Dänzer from comment #34)
> gdb cannot resolve symbols with only the core dump. Anyway, the screenshots
> showed the interesting parts of the backtrace. The problem is I have no clue
> how it could end up running the crashing code path.
I am not sure I understand this correctly. Maybe I am not getting the point
here, because I am not familiar with the intel platform (working on old
Mainframes instead), but from what I can get out of gdb is that the call stack
is pretty clear and the failure occurs in
hw/xfree86/drives/modesetting/driver.c in routine ms_dirty_update where
ent->slave_dst->drawable.pScreen-> SharedPixmapNotifyDamage(ent->slave_dst);
loads a zero address for the call.
The question is, which routine is responsible for setting up the structure in
ent->slave_dst->drawable.pScreen
and why is that not done correctly.
The related data areas seem to be all available in the core dump.
I agree that backtracking this is painful bit-counting, but it does not seem
out of reach.
I would first try to identify the routine that sets up
ent->slave_dst->drawable.pScreen
I have not tried this yet, because without a complete build setup on my machine
this is cumbersome task. I guess that with a ready development environment on
your side this is much easier to find out.
> We really need answers to the questions in comment 27.
I cannot set up a second machine. Due to network security restrictions here I
cannot connect between two PCs. And I do not have an external monitor in any
other location. So running a remote gdb debugging session is out of reach.
Also, this is my everyday production laptop, so I cannot conduct any wild
experiments on it.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
