From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#16358: combinatorial explosion in elided stack trace Date: Sun, 5 Jan 2014 23:02:38 +0000 Message-ID: <20140105230238.GC30283@fysh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388967689 19314 80.91.229.3 (6 Jan 2014 00:21:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 00:21:29 +0000 (UTC) To: 16358@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Jan 06 01:21:32 2014 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vzxwg-0004rV-L4 for guile-bugs@m.gmane.org; Mon, 06 Jan 2014 01:21:30 +0100 Original-Received: from localhost ([::1]:59940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzxwg-0006U0-6O for guile-bugs@m.gmane.org; Sun, 05 Jan 2014 19:21:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxNg-0005yQ-TO for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzxNT-0002RK-9f for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:20 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51434) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzxNT-0002RF-6o for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:07 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VzxNS-00051Z-Av for bug-guile@gnu.org; Sun, 05 Jan 2014 18:45:06 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 05 Jan 2014 23:45:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16358 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.138896546219162 (code B ref -1); Sun, 05 Jan 2014 23:45:06 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Jan 2014 23:44:22 +0000 Original-Received: from localhost ([127.0.0.1]:37201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzxMj-0004yt-VV for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:44:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45466) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vzwim-0003op-9U for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:03:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vzwid-0001h4-M9 for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:03:04 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:35512) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzwid-0001h0-J1 for submit@debbugs.gnu.org; Sun, 05 Jan 2014 18:02:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzwiX-0004Oj-9P for bug-guile@gnu.org; Sun, 05 Jan 2014 18:02:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzwiR-0001gS-A4 for bug-guile@gnu.org; Sun, 05 Jan 2014 18:02:49 -0500 Original-Received: from river.fysh.org ([5.135.154.127]:53130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzwiR-0001gN-46 for bug-guile@gnu.org; Sun, 05 Jan 2014 18:02:43 -0500 Original-Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1VzwiM-0000HF-9D; Sun, 05 Jan 2014 23:02:38 +0000 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Mailman-Approved-At: Sun, 05 Jan 2014 18:44:19 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-Mailman-Approved-At: Sun, 05 Jan 2014 19:21:12 -0500 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7373 Archived-At: In guile 2.0.9, if an error is signalled in the interpreter, and the stack contains in a certain position an object whose unabbreviated print representation is very large, then the process of displaying the stack trace will take a huge amount of time and memory, pausing in the middle of output, even though the displayed stack trace doesn't actually show the object at all. Test case: $ cat t6 (define bs (let aaa ((n 100) (v '())) (if (= n 0) v (aaa (- n 1) (cons v v))))) (write (list bs (error "wibble"))) $ guile-2.0 --no-auto-compile t6 Backtrace: In ice-9/boot-9.scm: 157: 11 [catch #t # ...] In unknown file: ?: 10 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 9 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 8 [eval # #] In ice-9/boot-9.scm: 2320: 7 [save-module-excursion #] 3968: 6 [#] 1645: 5 [%start-stack load-stack #] 1650: 4 [#] In unknown file: ?: 3 [primitive-load "/home/zefram/usr/guile/t6"] In ice-9/eval.scm: 387: 2 ^Z zsh: suspended guile-2.0 --no-auto-compile t6 $ jobs -l [1] + 32574 suspended guile-2.0 --no-auto-compile t6 $ ps vw 32574 PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND 32574 pts/5 T 0:36 0 3 2266300 1634556 9.9 guile-2.0 --no-auto-compile t6 With the test's size parameter at 100 as above, there is no realistic prospect of actually completing generation of the stack trace. For some range of values (about 25 on my machine) there will be a noticeable pause, after which the stack trace completes: ... 387: 2 [eval # ()] 387: 1 [eval # ()] In unknown file: ?: 0 [scm-error misc-error #f "~A" ("wibble") #f] It appears that it's generating the entire print representation of the object behind the scenes, though it then obviously throws it away. Experimentation with customising print methods for SRFI-9 record types shows that the delay and memory usage depend on the print representation per se, rather than on the amount of structure beneath the object. (A record-based cons-like type produces similar behaviour to the cons test when using the default print method that shows the content. Replacing it with a print method that emits a fixed string and doesn't recurse eliminates the delay entirely.) If my test program is run in compiled form (via auto-compilation) then it doesn't exhibit the pause. Actually it gets optimised such that the problem object isn't anywhere near what the stack trace displays, so for a fair test the program needs to be tweaked. It can be arranged for the problem object to be directly mentioned in the stack trace, and there is still no pause: the object appears in a highly abbreviated form, such as 2: 1 [vv ((# # # # ...) (# # # # ...) (# # # # ...) (# # # # ...) ...)] For comparison, guile-1.8 never exhibits this problem. By default it doesn't emit a stack trace for a script, but it can be asked to do so via --debug. It then behaves like the compiled form of guile-2.0: there is no delay, and the object is shown in very abbreviated form. Debian incarnation of this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734132 -zefram