From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 60929] [r600-llvm] mono games with opengl are blocking on start Date: Tue, 27 Aug 2013 05:22:38 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0186088638==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id D11B3E5FC1 for ; Mon, 26 Aug 2013 22:22:37 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0186088638== Content-Type: multipart/alternative; boundary="1377580957.ECCD1.3400"; charset="us-ascii" --1377580957.ECCD1.3400 Date: Tue, 27 Aug 2013 05:22:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #18 from Nicholas Miell --- (In reply to comment #17) > Thanks for tracking this down. I think we'll need to extend the LLVM C API > in order to get access to this variable. However, looking through the LLVM > code it looks like the PrettyStackTrace handler is registered by a static > initializer, so I wonder if setting this variable is enough and if we can > guarantee that r600g will set this variable before the handler is > initialized. I don't think this is true -- IIRC, all the stack traces I saw were the result of one of the runOnFunction methods (either BBPassManager or FPPassManager, I wasn't paying attention) creating a PassManagerPrettyStackEntry object. > Also, this seems to me like it is a bug in LLVM. Is it common practice for > libraries to override signal handlers of applications? Common enough that both Mono and LLVM stomp on each other, but its unambiguously wrong for a shared library to globally modify signal handlers. (Temporarily setting a new handler on entry to your library and later restoring the saved handler before returning is fine, but that only works in the single-threaded case since handlers aren't per-thread. Arguably modern applications shouldn't use any signals at all.) Mono (generally) gets away with it because it uses crazy signals that applications never touch (SIGPWR is only sent to PID 1 by the kernel on power failure, SIGXCPU is relic of obsolete job billing infrastructure that nobody uses), but had the bad luck of LLVM deciding to future-proof itself against all possible fatal signals. If I were to be prescriptive, llvm::DisablePrettyStackTrace should be true by default, should only ever be set by clang, and shouldn't be a global variable. -- You are receiving this mail because: You are the assignee for the bug. --1377580957.ECCD1.3400 Date: Tue, 27 Aug 2013 05:22:37 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 18 on bug 60929 from 
(In reply to comment #17)
> Thanks for tracking this down.  I think we'll need to extend the LLVM C API
> in order to get access to this variable.  However, looking through the LLVM
> code it looks like the PrettyStackTrace handler is registered by a static
> initializer, so I wonder if setting this variable is enough and if we can
> guarantee that r600g will set this variable before the handler is
> initialized.

I don't think this is true -- IIRC, all the stack traces I saw were the result
of one of the runOnFunction methods (either BBPassManager or FPPassManager, I
wasn't paying attention) creating a PassManagerPrettyStackEntry object.

> Also, this seems to me like it is a bug in LLVM.  Is it common practice for
> libraries to override signal handlers of applications?

Common enough that both Mono and LLVM stomp on each other, but its
unambiguously wrong for a shared library to globally modify signal handlers.
(Temporarily setting a new handler on entry to your library and later restoring
the saved handler before returning is fine, but that only works in the
single-threaded case since handlers aren't per-thread. Arguably modern
applications shouldn't use any signals at all.)

Mono (generally) gets away with it because it uses crazy signals that
applications never touch (SIGPWR is only sent to PID 1 by the kernel on power
failure, SIGXCPU is relic of obsolete job billing infrastructure that nobody
uses), but had the bad luck of LLVM deciding to future-proof itself against all
possible fatal signals.

If I were to be prescriptive, llvm::DisablePrettyStackTrace should be true by
default, should only ever be set by clang, and shouldn't be a global variable.

You are receiving this mail because:
  • You are the assignee for the bug.
--1377580957.ECCD1.3400-- --===============0186088638== 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 --===============0186088638==--