From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 82828] Regression: Crash in 3Dmark2001
Date: Sat, 30 Aug 2014 20:50:32 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1046287825=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 214866E36F
for ; Sat, 30 Aug 2014 13:50:32 -0700 (PDT)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============1046287825==
Content-Type: multipart/alternative; boundary="1409431832.141AF5683.12207"; charset="us-ascii"
--1409431832.141AF5683.12207
Date: Sat, 30 Aug 2014 20:50:32 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=82828
--- Comment #7 from Connor Abbott ---
Oh, and I forgot to mention:
If you do find that g->nodes[n2].reg is NO_REG, the next step would be to break
at the end of ra_simplify() (but make sure to stop at the last time the
breakpoint gets hit before the segfault using the stackoverflow post I linked
to) and print out the values of all the nodes (g->nodes[0], g->nodes[1], ...,
g->nodes[g->count - 1]). All the ones with .reg = NO_REG should also have
.in_stack = true. If one has .reg = NO_REG and .in_stack = false, then in
ra_simplify() we should have reached line 468, in which case we either push it
onto the stack (if pq_test() returns true) or considered it for optimistic
coloring (if pq_test() returns false). So if we finished the loop, then
progress == false and so no nodes were pushed on the stack and no nodes were
considered for optimistic coloring (see the places where we set progress =
true), so no nodes should have .reg = NO_REG and .in_stack = false when we
leave ra_simplify(). Then, in ra_select(), whenever we set .in_stack = false
(line 536) we also set .reg to something else (line 541) unless we run out of
registers in which case we bail out and then r300g will complain about running
out of registers. So it seems strange to me that that would happen, but also
the most likely explanation of why it's segfaulting.
--
You are receiving this mail because:
You are the assignee for the bug.
--1409431832.141AF5683.12207
Date: Sat, 30 Aug 2014 20:50:32 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Comment # 7
on bug 82828
from Connor Abbott
Oh, and I forgot to mention:
If you do find that g->nodes[n2].reg is NO_REG, the next step would be to break
at the end of ra_simplify() (but make sure to stop at the last time the
breakpoint gets hit before the segfault using the stackoverflow post I linked
to) and print out the values of all the nodes (g->nodes[0], g->nodes[1], ...,
g->nodes[g->count - 1]). All the ones with .reg = NO_REG should also have
.in_stack = true. If one has .reg = NO_REG and .in_stack = false, then in
ra_simplify() we should have reached line 468, in which case we either push it
onto the stack (if pq_test() returns true) or considered it for optimistic
coloring (if pq_test() returns false). So if we finished the loop, then
progress == false and so no nodes were pushed on the stack and no nodes were
considered for optimistic coloring (see the places where we set progress =
true), so no nodes should have .reg = NO_REG and .in_stack = false when we
leave ra_simplify(). Then, in ra_select(), whenever we set .in_stack = false
(line 536) we also set .reg to something else (line 541) unless we run out of
registers in which case we bail out and then r300g will complain about running
out of registers. So it seems strange to me that that would happen, but also
the most likely explanation of why it's segfaulting.
You are receiving this mail because:
- You are the assignee for the bug.
--1409431832.141AF5683.12207--
--===============1046287825==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--===============1046287825==--