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
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==--