23.1; json-read-string crashes emacs with long string

unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed

* 23.1; json-read-string crashes emacs with long string
@ 2010-05-18 16:08 Carl Worth
  2010-05-18 18:07 ` bug#6214: " Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Carl Worth @ 2010-05-18 16:08 UTC (permalink / raw)
  To: bug-gnu-emacs; +Cc: Notmuch mailing list

> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:

A user of the emacs-based mail client, Notmuch [*], found that
attempting to display a particular message would consistently
causes a segmentation fault in emacs.

I tracked this down to calling `json-read-string' with a very long
string, (roughly 1 million characters). Rather than including that
enormous string in this message, here's a little snippet of emacs lisp
that creates and reads such a string. So, if evaluated, this code should
trigger the segmentation fault, (assuming a copy of GPLv3 exists at
/usr/share/emacs/23.1/etc/COPYING---adjust the filename if necessary).

;; Caution: Evaluating the block below has been known to crash emacs
(with-temp-buffer
  (require 'json)
  ;; First we just need a lot of text. 32 copies of GPLv3 seems to do it
  (dotimes (i 32)
    (insert-file "/usr/share/emacs/23.1/etc/COPYING"))
  ;; Now create a buffer with a json-encoded version of the text
  (let ((json-string (json-encode-string (buffer-string))))
    (with-temp-buffer
      (insert json-string)
      (goto-char (point-min))
      ;; And try to read the string. This triggers the segfault.
      (json-read-string))))

> If Emacs crashed, and you have the Emacs process in the gdb debugger,
> please include the output from the following gdb commands:
>    `bt full' and `xbacktrace'.

I haven't attempted to debug this within gdb yet, (I'll have to get my
hands on a build of emacs with debugging symbols first). But I wanted to
share things right away, so that perhaps someone else could do further
debugging and follow up.

In the meantime, notmuch folks, if you've got a good idea for modifying
notmuch to avoid this bug I'd be glad to hear it. Adjust followups to
include the notmuch list and not the gnu.org bug address as appropriate.

-Carl

[*] http://notmuchmail.org

PS. Here are some of the details provided by `report-emacs-bug':

In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.2)
 of 2010-01-26 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10799001
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

-- 
carl.d.worth@intel.com

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-05-18 16:08 23.1; json-read-string crashes emacs with long string Carl Worth
@ 2010-05-18 18:07 ` Chong Yidong
  2010-08-12 21:58   ` Michal Sojka
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-05-18 18:07 UTC (permalink / raw)
  To: Carl Worth; +Cc: Notmuch mailing list, 6214-done

Carl Worth <cworth@cworth.org> writes:

> A user of the emacs-based mail client, Notmuch [*], found that
> attempting to display a particular message would consistently
> causes a segmentation fault in emacs.
>
> I haven't attempted to debug this within gdb yet, (I'll have to get my
> hands on a build of emacs with debugging symbols first). But I wanted to
> share things right away, so that perhaps someone else could do further
> debugging and follow up.

Looks like a stack overflow in the `string' function.  I've checked in a
fix, thanks for the bug report.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-05-18 18:07 ` bug#6214: " Chong Yidong
@ 2010-08-12 21:58   ` Michal Sojka
  2010-08-13 16:37     ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Sojka @ 2010-08-12 21:58 UTC (permalink / raw)
  To: Chong Yidong, Carl Worth; +Cc: 6214, Notmuch mailing list

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Tue, 18 May 2010, Chong Yidong wrote:
> Looks like a stack overflow in the `string' function.  I've checked in a
> fix, thanks for the bug report.

It seems the bug is still in the current Emacs HEAD
(http://repo.or.cz/w/emacs.git/commit/08d1bfbda3ef4a7038556f6c56bec1a37b4721f0).
I can reproduce it with the lisp code sent by Carl, but the backtrace is
different. My backtrace is attached.

Thanks
Michal

[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 24831 bytes --]

#0  0x0000000000566739 in Fapply (nargs=2, args=0x7fffffffbcf8) at eval.c:2492
        i = 8997664
        numargs = <value optimized out>
        spread_arg = 12020694
        funcall_args = 0x7fffff767100
        fun = <value optimized out>
#1  0x0000000000565135 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2964
        fun = <value optimized out>
        original_fun = 11891218
        funcar = <value optimized out>
        numargs = 2
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffbf00, 
          function = 0x7fffffffbcf0, 
          args = 0x7fffffffbcf8, 
          nargs = 2, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffbcf8
        i = <value optimized out>
#2  0x000000000059ecd2 in Fbyte_code (bytestr=<value optimized out>, vector=<value optimized out>, maxdepth=<value optimized out>) at bytecode.c:679
        count = 47
        op = <value optimized out>
        stack = {
          pc = 0xea5250 "\202|", 
          top = 0x7fffffffbd00, 
          bottom = 0x7fffffffbcf0, 
          byte_string = 18230033, 
          byte_string_start = 0xea51d8 "\303`f\211\030\206\t", 
          constants = 18231925, 
          next = 0x7fffffffce20
        }
        top = 0x7fffffffbcf0
        result = <value optimized out>
#3  0x00000000005672ef in funcall_lambda (fun=18232277, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:3165
        val = <value optimized out>
        syms_left = 11721042
        next = 0
        i = 0
        optional = 0
        rest = 0
#4  0x0000000000567454 in apply_lambda (fun=18232277, args=11721042, eval_flag=<value optimized out>) at eval.c:3092
        args_left = 11721042
        i = <value optimized out>
        tem = <value optimized out>
#5  0x0000000000566b53 in Feval (form=18232272) at eval.c:2408
        fun = 140737479340288
        val = <value optimized out>
        original_fun = 17897138
        original_args = 11721042
        funcar = 8997664
        backtrace = {
          next = 0x7fffffffbfe0, 
          function = 0x7fffffffbf28, 
          args = 0x7fffffffbe30, 
          nargs = 0, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#6  0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#7  0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 11697014
        i = <value optimized out>
        argvals = {11721042, 74852149, 74124673, 11721042, 1, 140737488339112, 140737488338912, 5892710}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890130
        original_args = 11697014
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc0d0, 
          function = 0x7fffffffc008, 
          args = 0x7fffffffc000, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#8  0x0000000000567505 in Funwind_protect (args=11695302) at eval.c:1304
        val = <value optimized out>
#9  0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 11695302
        i = <value optimized out>
        argvals = {74852149, 5665519, 74852149, 74124801, 140737488339352, 21480469067, 17767008, 17768448}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890930
        original_args = 11695302
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc1d0, 
          function = 0x7fffffffc0f8, 
          args = 0x7fffffffc0f0, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#10 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#11 0x000000000055951d in Fsave_current_buffer (args=11693078) at editfns.c:1012
        val = <value optimized out>
#12 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 11693078
        i = <value optimized out>
        argvals = {8633005, 18237426, 11695062, 11695030, 140737488339456, 5662408, 1, 2}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11928034
        original_args = 11693078
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc2a0, 
          function = 0x7fffffffc1f8, 
          args = 0x7fffffffc1f0, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#13 0x0000000000566cec in Feval (form=<value optimized out>) at eval.c:2406
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 12595842
        original_args = 11695030
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc3f0, 
          function = 0x7fffffffc2c8, 
          args = 0x7fffffffc2c0, 
          nargs = -1, 
          evalargs = 1 '\001', 
          debug_on_exit = 0 '\000'
        }
#14 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#15 0x0000000000567d08 in Flet (args=11694902) at eval.c:1051
        tem = 74852149
        elt = <value optimized out>
        varlist = <value optimized out>
#16 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 11694902
        i = <value optimized out>
        argvals = {8635685, 18755398, 18755446, 18755510, 140737488340000, 5662408, 1, 2}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890562
        original_args = 11694902
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc4c0, 
          function = 0x7fffffffc418, 
          args = 0x7fffffffc410, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#17 0x0000000000566cec in Feval (form=<value optimized out>) at eval.c:2406
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 12606802
        original_args = 18755430
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc610, 
          function = 0x7fffffffc4e8, 
          args = 0x7fffffffc4e0, 
          nargs = -1, 
          evalargs = 1 '\001', 
          debug_on_exit = 0 '\000'
        }
#18 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#19 0x0000000000567d08 in Flet (args=18755366) at eval.c:1051
        tem = 74125073
        elt = <value optimized out>
        varlist = <value optimized out>
#20 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 18755366
        i = <value optimized out>
        argvals = {17896994, 11721042, 11721042, 5561631, 140737488340688, 5708090, 41, 0}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890562
        original_args = 18755366
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc6f0, 
          function = 0x7fffffffc638, 
          args = 0x7fffffffc630, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#21 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#22 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 18752566
        i = <value optimized out>
        argvals = {11721042, 15322325, 15321809, 11721042, 1, 140737488340920, 140737488340720, 17986768}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890130
        original_args = 18752566
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc7e0, 
          function = 0x7fffffffc718, 
          args = 0x7fffffffc710, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#23 0x0000000000567505 in Funwind_protect (args=18752758) at eval.c:1304
        val = <value optimized out>
#24 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 18752758
        i = <value optimized out>
        argvals = {15322325, 5665519, 15322325, 8618505, 140737488341160, 21474836480, 17767008, 17768320}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890930
        original_args = 18752758
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc8e0, 
          function = 0x7fffffffc808, 
          args = 0x7fffffffc800, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#25 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#26 0x000000000055951d in Fsave_current_buffer (args=18752966) at editfns.c:1012
        val = <value optimized out>
#27 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 18752966
        i = <value optimized out>
        argvals = {8633005, 17897186, 18752774, 18752806, 140737488341264, 5662408, 1, 2}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11928034
        original_args = 18752966
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffc9b0, 
          function = 0x7fffffffc908, 
          args = 0x7fffffffc900, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#28 0x0000000000566cec in Feval (form=<value optimized out>) at eval.c:2406
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 12595842
        original_args = 18752806
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffcb00, 
          function = 0x7fffffffc9d8, 
          args = 0x7fffffffc9d0, 
          nargs = -1, 
          evalargs = 1 '\001', 
          debug_on_exit = 0 '\000'
        }
#29 0x00000000005670c7 in Fprogn (args=<value optimized out>) at eval.c:395
        val = 8997664
#30 0x0000000000567d08 in Flet (args=18752854) at eval.c:1051
        tem = 15322325
        elt = <value optimized out>
        varlist = <value optimized out>
#31 0x0000000000566ec4 in Feval (form=<value optimized out>) at eval.c:2295
        numargs = 8997664
        args_left = 18752854
        i = <value optimized out>
        argvals = {8635685, 18755046, 18755126, 18755254, 140737488341808, 5662408, 11739872, 2}
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 11890562
        original_args = 18752854
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffcbd0, 
          function = 0x7fffffffcb28, 
          args = 0x7fffffffcb20, 
          nargs = -1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#32 0x0000000000566cec in Feval (form=<value optimized out>) at eval.c:2406
        fun = <value optimized out>
        val = <value optimized out>
        original_fun = 12606802
        original_args = 18755110
        funcar = <value optimized out>
        backtrace = {
          next = 0x7fffffffcd70, 
          function = 0x7fffffffcbf8, 
          args = 0x7fffffffcbf0, 
          nargs = -1, 
          evalargs = 1 '\001', 
          debug_on_exit = 0 '\000'
        }
#33 0x000000000058ae4f in readevalloop (readcharfun=18093061, stream=0x0, sourcename=18361409, printflag=<value optimized out>, unibyte=<value optimized out>, readfun=<value optimized out>, start=11721042, end=11721042, 
    evalfun=<value optimized out>) at lread.c:1739
        count1 = 40
        c = <value optimized out>
        val = <value optimized out>
        b = 0x1141400
        continue_reading_p = 1
        whole_buffer = 1
        first_sexp = <value optimized out>
#34 0x000000000058bb71 in Feval_buffer (buffer=<value optimized out>, printflag=11721042, filename=15002881, unibyte=11721042, do_allow_print=<value optimized out>) at lread.c:1799
        tem = <value optimized out>
        buf = 18093061
#35 0x0000000000565073 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2997
        fun = <value optimized out>
        original_fun = <value optimized out>
        funcar = <value optimized out>
        numargs = 5
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffcf30, 
          function = 0x7fffffffcdd0, 
          args = 0x7fffffffcdd8, 
          nargs = 5, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffcdd8
        i = 5
#36 0x000000000059ecd2 in Fbyte_code (bytestr=<value optimized out>, vector=<value optimized out>, maxdepth=<value optimized out>) at bytecode.c:679
        count = 27
        op = <value optimized out>
        stack = {
          pc = 0xaa6e3a "\210,\336\b!\210\016\"\204\256", 
          top = 0x7fffffffcdf8, 
          bottom = 0x7fffffffcdd0, 
          byte_string = 8682273, 
          byte_string_start = 0xaa6dae "\306\b!\204\022", 
          constants = 8682309, 
          next = 0x7fffffffd2c0
        }
        top = 0x7fffffffcdd0
        result = <value optimized out>
#37 0x00000000005672ef in funcall_lambda (fun=8682141, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:3165
        val = <value optimized out>
        syms_left = 11721042
        next = 12593154
        i = 4
        optional = 1
        rest = 0
#38 0x0000000000564f03 in Ffuncall (nargs=<value optimized out>, args=0x847a98) at eval.c:3040
        fun = 140737479340288
        original_fun = 12593010
        funcar = 8997664
        numargs = 4
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffd1f0, 
          function = 0x7fffffffcf90, 
          args = 0x7fffffffcf98, 
          nargs = 4, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffcf98
        i = <value optimized out>
#39 0x00000000005652d9 in call4 (fn=<value optimized out>, arg1=<value optimized out>, arg2=16, arg3=8473480, arg4=0) at eval.c:2831
        ret_ungc_val = 8997664
        args = {12593010, 15002881, 15002881, 11721042, 11721090}
#40 0x000000000058b71d in Fload (file=18663777, noerror=8473480, nomessage=11721090, nosuffix=<value optimized out>, must_suffix=<value optimized out>) at lread.c:1183
        val = <value optimized out>
        stream = <value optimized out>
        fd = 5
        count = 20
        found = 15002881
        efound = <value optimized out>
        hist_file_name = 15002881
        newer = 0
        compiled = 17487280
        handler = <value optimized out>
        safe_p = 17767648
        tmp = {18737654, 13154870}
        version = 0
#41 0x0000000000565073 in Ffuncall (nargs=<value optimized out>, args=<value optimized out>) at eval.c:2997
        fun = <value optimized out>
        original_fun = <value optimized out>
        funcar = <value optimized out>
        numargs = 5
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffd3d0, 
          function = 0x7fffffffd250, 
          args = 0x7fffffffd258, 
          nargs = 3, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffd1a0
        i = 5
#42 0x000000000059ecd2 in Fbyte_code (bytestr=<value optimized out>, vector=<value optimized out>, maxdepth=<value optimized out>) at bytecode.c:679
        count = 5
        op = <value optimized out>
        stack = {
          pc = 0xa88814 "\210*\202\300\003\016L띃!\002\347\016N\206\f\002\f\211A\024@!\036S\346\016S!\036T\352\016T\314ى$\210*\202\300\003\016L욃J\002\331\026Q\016N\206\065\002\f\211A\024@\211\026F;\204@\002\332\355!\210\356\347\016F!!\210\202\300\003\016LX\002\360\331!\210\202\300\003\016L\361\232\203f\002\362\363!\210\202\300\003\321\364\016L\"\203w\002\365\016L!\026B\202\300\003\321\366\016L\"\203\224\002\365\325\326\016L\"!\026B\365\325\367\016L\"!\026A\202\300\003\334\016M\016H\"\211\026F\203\252\002\016FA@\f\233\024\202\300\003\334\016M\016K\"\211\026F\203\300\002\016FA@\f\233\024"..., 
          top = 0x7fffffffd268, 
          bottom = 0x7fffffffd250, 
          byte_string = 9032857, 
          byte_string_start = 0xa8861f "\306 \210\b\203\021", 
          constants = 9032893, 
          next = 0x7fffffffd490
        }
        top = 0x7fffffffd250
        result = <value optimized out>
#43 0x00000000005672ef in funcall_lambda (fun=9032797, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:3165
        val = <value optimized out>
        syms_left = 11721042
        next = 13750050
        i = 1
        optional = 0
        rest = 0
#44 0x0000000000564f03 in Ffuncall (nargs=<value optimized out>, args=0x89d458) at eval.c:3040
        fun = 140737479340288
        original_fun = 13756226
        funcar = 8997664
        numargs = 1
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffd5a0, 
          function = 0x7fffffffd430, 
          args = 0x7fffffffd438, 
          nargs = 1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffd438
        i = <value optimized out>
#45 0x000000000059ecd2 in Fbyte_code (bytestr=<value optimized out>, vector=<value optimized out>, maxdepth=<value optimized out>) at bytecode.c:679
        count = 4
        op = <value optimized out>
        stack = {
          pc = 0xa8b2dc "\210\016N\203s\006\201", <incomplete sequence \346>, 
          top = 0x7fffffffd438, 
          bottom = 0x7fffffffd430, 
          byte_string = 9005745, 
          byte_string_start = 0xa8ac75 "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064", 
          constants = 9005781, 
          next = 0x7fffffffd650
        }
        top = 0x7fffffffd430
        result = <value optimized out>
#46 0x00000000005672ef in funcall_lambda (fun=9005701, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:3165
        val = <value optimized out>
        syms_left = 11721042
        next = 12575218
        i = 0
        optional = 0
        rest = 2
#47 0x0000000000564f03 in Ffuncall (nargs=<value optimized out>, args=0x896a80) at eval.c:3040
        fun = 140737479340288
        original_fun = 12575218
        funcar = 8997664
        numargs = 0
        val = <value optimized out>
        backtrace = {
          next = 0x7fffffffd810, 
          function = 0x7fffffffd600, 
          args = 0x7fffffffd608, 
          nargs = 0, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffd608
        i = <value optimized out>
#48 0x000000000059ecd2 in Fbyte_code (bytestr=<value optimized out>, vector=<value optimized out>, maxdepth=<value optimized out>) at bytecode.c:679
        count = 2
        op = <value optimized out>
        stack = {
          pc = 0xa8ba98 "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251", 
          top = 0x7fffffffd600, 
          bottom = 0x7fffffffd600, 
          byte_string = 9000737, 
          byte_string_start = 0xa8ba0a "\b\203\b", 
          constants = 9000773, 
          next = 0x0
        }
        top = 0x7fffffffd600
        result = <value optimized out>
#49 0x00000000005672ef in funcall_lambda (fun=9000693, nargs=<value optimized out>, arg_vector=<value optimized out>) at eval.c:3165
        val = <value optimized out>
        syms_left = 11721042
        next = 0
        i = 0
        optional = 32767
        rest = 0
#50 0x0000000000567454 in apply_lambda (fun=9000693, args=11721042, eval_flag=<value optimized out>) at eval.c:3092
        args_left = 11721042
        i = <value optimized out>
        tem = <value optimized out>
#51 0x0000000000566b53 in Feval (form=9000688) at eval.c:2408
        fun = 140737479340288
        val = <value optimized out>
        original_fun = 13749474
        original_args = 11721042
        funcar = 8997664
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffd838, 
          args = 0x7fffffffd740, 
          nargs = 0, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
#52 0x000000000056437d in internal_condition_case (bfun=<value optimized out>, handlers=<value optimized out>, hfun=<value optimized out>) at eval.c:1458
        val = 8997664
        c = {
          tag = 11721042, 
          val = 11721042, 
          next = 0x7fffffffda10, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {13365184, 3949921905019383304, 13365216, 140737488346744, 1, 1, -3949921426383376888, 3949920965887585800}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {140737353880784, 140737353835656, 4294967295, 4238812, 1, 8460504, 0, 1, 1, 0, 140737351959490, 140733193388033, 0, 140737488345816, 140737251616176, 226670640}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 11773138, 
          var = 11721042, 
          chosen_clause = 11721042, 
          tag = 0x7fffffffd8a0, 
          next = 0x0
        }
#53 0x00000000004f9e06 in top_level_1 (ignore=<value optimized out>) at keyboard.c:1355
No locals.
#54 0x00000000005644a8 in internal_catch (tag=<value optimized out>, func=<value optimized out>, arg=<value optimized out>) at eval.c:1202
        c = {
          tag = 11769202, 
          val = 11721042, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {13365184, 3949921905019383304, 13365216, 140737488346744, 1, 1, -3949921426333045240, 3949920965646937608}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {0, 0, 0, 0, 112, 140737255104152, 352, 140737255104152, 140737255104168, 30064771072, 344, 94489280656, 30064771072, 384, 94489280612, 11993394}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#55 0x00000000004f9e7b in command_loop () at keyboard.c:1310
No locals.
#56 0x00000000004fa278 in recursive_edit_1 () at keyboard.c:940
        val = <value optimized out>
#57 0x00000000004fa3b7 in Frecursive_edit () at keyboard.c:1002
        buffer = 11721042
#58 0x00000000004ed995 in main (argc=0, argv=0x7fffffffdf98) at emacs.c:1764
        dummy = 0
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = <value optimized out>
        skip_args = 1
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x0

Lisp Backtrace:
"apply" (0xffffbcf8)
"json-read-string" (0xffffbe30)
"progn" (0xffffc000)
"unwind-protect" (0xffffc0f0)
"save-current-buffer" (0xffffc1f0)
"with-current-buffer" (0xffffc2c0)
"let" (0xffffc410)
"with-temp-buffer" (0xffffc4e0)
"let" (0xffffc630)
"progn" (0xffffc710)
"unwind-protect" (0xffffc800)
"save-current-buffer" (0xffffc900)
"with-current-buffer" (0xffffc9d0)
"let" (0xffffcb20)
"with-temp-buffer" (0xffffcbf0)
"eval-buffer" (0xffffcdd8)
"load-with-code-conversion" (0xffffcf98)
"load" (0xffffd258)
"command-line-1" (0xffffd438)
"command-line" (0xffffd608)
"normal-top-level" (0xffffd740)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-12 21:58   ` Michal Sojka
@ 2010-08-13 16:37     ` Chong Yidong
  2010-08-14  7:39       ` Michal Sojka
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-08-13 16:37 UTC (permalink / raw)
  To: Michal Sojka; +Cc: 6214, Notmuch mailing list

Michal Sojka <sojkam1@fel.cvut.cz> writes:

> It seems the bug is still in the current Emacs HEAD
> (http://repo.or.cz/w/emacs.git/commit/08d1bfbda3ef4a7038556f6c56bec1a37b4721f0).
> I can reproduce it with the lisp code sent by Carl, but the backtrace is
> different. My backtrace is attached.

I can't reproduce it with the BZR repository.  Maybe the git mirror you
are using is not up to date.  Without any further information from you
about your Emacs build (information that would have been available if
you had used `M-x report-emacs-bug'), it is impossible to say.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-13 16:37     ` Chong Yidong
@ 2010-08-14  7:39       ` Michal Sojka
  2010-08-14 21:30         ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Sojka @ 2010-08-14  7:39 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 6214, Notmuch mailing list

On Fri, 13 Aug 2010, Chong Yidong wrote:
> Michal Sojka <sojkam1@fel.cvut.cz> writes:
> 
> > It seems the bug is still in the current Emacs HEAD
> > (http://repo.or.cz/w/emacs.git/commit/08d1bfbda3ef4a7038556f6c56bec1a37b4721f0).
> > I can reproduce it with the lisp code sent by Carl, but the backtrace is
> > different. My backtrace is attached.
> 
> I can't reproduce it with the BZR repository.  Maybe the git mirror you
> are using is not up to date.  Without any further information from you
> about your Emacs build (information that would have been available if
> you had used `M-x report-emacs-bug'), it is impossible to say.

I cloned bzr repo (trunk:101071) and I can reproduce the bug (./emacs
--batch -l ~/q/json-emacs-bug.el). Backtrace is the same as in my
previous mail and report-emacs-bug information is bellow. Let me know if
you need additional info.

Thanks
-Michal



In GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2010-08-14 on steelpick
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t SPC e m a SPC SPC <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message sendmail regexp-opt rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mailabbrev mail-utils
gmm-utils mailheader emacsbug package warnings tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-14  7:39       ` Michal Sojka
@ 2010-08-14 21:30         ` Chong Yidong
  2010-08-15  7:37           ` Michal Sojka
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-08-14 21:30 UTC (permalink / raw)
  To: Michal Sojka; +Cc: 6214, Notmuch mailing list

Michal Sojka <sojkam1@fel.cvut.cz> writes:

> I cloned bzr repo (trunk:101071) and I can reproduce the bug (./emacs
> --batch -l ~/q/json-emacs-bug.el). Backtrace is the same as in my
> previous mail and report-emacs-bug information is bellow. Let me know if
> you need additional info.

First, please check if this equivalent and simpler recipe also
reproduces the problem, to make sure this is the same bug:

  emacs --batch -q --eval "(apply 'string (make-list 1122176 ?a)))"

If so, please recompile without optimizations:

  CFLAGS="-g" ./configure
  make

and see if you can obtain a cleaner backtrace.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-14 21:30         ` Chong Yidong
@ 2010-08-15  7:37           ` Michal Sojka
  2010-08-16 17:40             ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Sojka @ 2010-08-15  7:37 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 6214, Notmuch mailing list

On Sat, 14 Aug 2010, Chong Yidong wrote:
> First, please check if this equivalent and simpler recipe also
> reproduces the problem, to make sure this is the same bug:
> 
>   emacs --batch -q --eval "(apply 'string (make-list 1122176 ?a)))"

Yes, the problem is still here.

> If so, please recompile without optimizations:
> 
>   CFLAGS="-g" ./configure
>   make
> 
> and see if you can obtain a cleaner backtrace.

Program received signal SIGSEGV, Segmentation fault.
0x00000000005f81fc in Fapply (nargs=2, args=0x7fffffffc670) at eval.c:2492
2492	  memcpy (funcall_args, args, nargs * sizeof (Lisp_Object));
#0  0x00000000005f81fc in Fapply (nargs=2, args=0x7fffffffc670) at eval.c:2492
        i = 0
        numargs = 1122176
        spread_arg = 38164022
        funcall_args = 0x7fffff76c9d0
        fun = 9260085
        gcpro1 = {
          next = 0x2465636, 
          var = 0x95cb41, 
          nvars = 1122177
        }
#1  0x00000000005f7ade in Feval (form=19244870) at eval.c:2321
        vals = 0x7fffffffc670
        argnum = 2
        numargs = 8
        args_left = 12507474
        i = 2
        maxargs = -14728
        argvals = {19244854, 18642001, 0, 6, 6, 25769803776, 16350976, 12420200}
        fun = 12011021
        val = 24
        original_fun = 12677650
        original_args = 19244918
        funcar = 19244870
        backtrace = {
          next = 0x7fffffffc800, 
          function = 0x7fffffffc770, 
          args = 0x7fffffffc670, 
          nargs = 2, 
          evalargs = 1 '\001', 
          debug_on_exit = 0 '\000'
        }
        gcpro1 = {
          next = 0x0, 
          var = 0x11c7471, 
          nvars = 39
        }
        gcpro2 = {
          next = 0x0, 
          var = 0x7fffffffd530, 
          nvars = -14512
        }
        gcpro3 = {
          next = 0x125a416, 
          var = 0x7fffffffc670, 
          nvars = 2
        }
#2  0x00000000005f8ead in Ffuncall (nargs=2, args=0x7fffffffc880) at eval.c:2983
        fun = 12010973
        original_fun = 12677602
        funcar = 9817142
        numargs = 1
        lisp_numargs = 6302634
        val = 19244870
        backtrace = {
          next = 0x7fffffffcc80, 
          function = 0x7fffffffc880, 
          args = 0x7fffffffc888, 
          nargs = 1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x7fffffffc888
        i = 0
#3  0x0000000000645887 in Fbyte_code (bytestr=9815377, vector=9815413, maxdepth=40) at bytecode.c:679
        count = 5
        op = 1
        vectorp = 0x95c580
        bytestr_length = 1187
        stack = {
          pc = 0xb48b63 "\210\202\300\003\016L坃\311\001\346\347\016N\206\241\001\f\211A\024@!!\026F\016E\203\274\001\016E\016F\016EAB\241\210\016EA\026E\202\300\003\016F\016RB\211\026R\026E\202\300\003\016L蝃\372\001\347\016N\206\333\001\f\211A\024@!\036S\346\016S!\036T\351\016T!\203\357\001\016T\026S\352\016S\314\331#\210*\202\300\003\016L띃!\002\347\016N\206\f\002\f\211A\024@!\036S\346\016S!\036T\352\016T\314ى$\210*\202\300\003\016L욃J\002\331\026Q\016N\206\065\002\f\211A\024@\211\026F;\204@\002\332\355!\210\356\347\016F!!\210\202\300\003\016LX\002", <incomplete sequence \360>..., 
          top = 0x7fffffffc888, 
          bottom = 0x7fffffffc880, 
          byte_string = 9815377, 
          byte_string_start = 0xb489d9 "\306 \210\b\203\021", 
          constants = 9815413, 
          next = 0x7fffffffcd70
        }
        top = 0x7fffffffc880
        result = 140737488341184
#4  0x00000000005f9701 in funcall_lambda (fun=9815317, nargs=1, arg_vector=0x7fffffffcd08) at eval.c:3165
        val = 12535520
        syms_left = 12507474
        next = 14517122
        count = 4
        i = 1
        optional = 0
        rest = 0
#5  0x00000000005f90bb in Ffuncall (nargs=2, args=0x7fffffffcd00) at eval.c:3029
        fun = 9815317
        original_fun = 14191698
        funcar = 12535520
        numargs = 1
        lisp_numargs = 6152191
        val = 19245862
        backtrace = {
          next = 0x7fffffffd0f0, 
          function = 0x7fffffffcd00, 
          args = 0x7fffffffcd08, 
          nargs = 1, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0x125ab36
        i = 0
#6  0x0000000000645887 in Fbyte_code (bytestr=9788449, vector=9788485, maxdepth=28) at bytecode.c:679
        count = 4
        op = 1
        vectorp = 0x955c50
        bytestr_length = 1723
        stack = {
          pc = 0xb4b681 "\210\016N\203^\006\201", <incomplete sequence \343>, 
          top = 0x7fffffffcd08, 
          bottom = 0x7fffffffcd00, 
          byte_string = 9788449, 
          byte_string_start = 0xb4b02f "\306 \020\307\021\n\023\307\024\310\311!\211\035\307=\204\064", 
          constants = 9788485, 
          next = 0x7fffffffd1d0
        }
        top = 0x7fffffffcd00
        result = 13467377
#7  0x00000000005f9701 in funcall_lambda (fun=9788405, nargs=0, arg_vector=0x7fffffffd178) at eval.c:3165
        val = 12535520
        syms_left = 12507474
        next = 13258642
        count = 4
        i = 0
        optional = 0
        rest = 0
#8  0x00000000005f90bb in Ffuncall (nargs=1, args=0x7fffffffd170) at eval.c:3029
        fun = 9788405
        original_fun = 13569954
        funcar = 13569906
        numargs = 0
        lisp_numargs = 6152191
        val = 13467377
        backtrace = {
          next = 0x7fffffffd6c0, 
          function = 0x7fffffffd170, 
          args = 0x7fffffffd178, 
          nargs = 0, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        internal_args = 0xcd7ef1
        i = 0
#9  0x0000000000645887 in Fbyte_code (bytestr=9783473, vector=9783509, maxdepth=24) at bytecode.c:679
        count = 2
        op = 0
        vectorp = 0x9548e0
        bytestr_length = 220
        stack = {
          pc = 0xb4be2e "\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251", 
          top = 0x7fffffffd170, 
          bottom = 0x7fffffffd170, 
          byte_string = 9783473, 
          byte_string_start = 0xb4bda0 "\b\203\b", 
          constants = 9783509, 
          next = 0x0
        }
        top = 0x7fffffffd170
        result = 4294967295
#10 0x00000000005f9701 in funcall_lambda (fun=9783429, nargs=0, arg_vector=0x7fffffffd530) at eval.c:3165
        val = 1
        syms_left = 12507474
        next = 140733193388033
        count = 2
        i = 0
        optional = 0
        rest = 0
#11 0x00000000005f932f in apply_lambda (fun=9783429, args=12507474, eval_flag=1) at eval.c:3092
        args_left = 12507474
        numargs = 0
        arg_vector = 0x7fffffffd530
        gcpro1 = {
          next = 0x7ffff1e40970, 
          var = 0x7ffff7fc14d0, 
          nvars = 0
        }
        gcpro2 = {
          next = 0x83b, 
          var = 0x1000, 
          nvars = 8
        }
        gcpro3 = {
          next = 0x1, 
          var = 0x81a4, 
          nvars = 0
        }
        i = 0
        tem = 5
#12 0x00000000005f7dea in Feval (form=12978838) at eval.c:2390
        fun = 9783429
        val = 140737488345192
        original_fun = 14516546
        original_args = 12507474
        funcar = 140737354130560
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffd6f0, 
          args = 0x7fffffffd530, 
          nargs = 0, 
          evalargs = 0 '\000', 
          debug_on_exit = 0 '\000'
        }
        gcpro1 = {
          next = 0x7ffff7fb6488, 
          var = 0x7ffff7fc14d0, 
          nvars = -134225624
        }
        gcpro2 = {
          next = 0x7fffffffd810, 
          var = 0x7ffff1e34c28, 
          nvars = -236739152
        }
        gcpro3 = {
          next = 0x0, 
          var = 0x7fff00000017, 
          nvars = 44108294
        }
#13 0x00000000005599d1 in top_level_2 () at keyboard.c:1347
No locals.
#14 0x00000000005f5f8c in internal_condition_case (bfun=0x5599be <top_level_2>, handlers=12559570, hfun=0x5595a8 <cmd_error>) at eval.c:1458
        val = 5609939
        c = {
          tag = 12507474, 
          val = 12507474, 
          next = 0x7fffffffd930, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {5, 7988929332933021680, 4279008, 140737488346960, 0, 0, 7988929332880592880, -7988928721167724560}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {4294967295, 140737488345248, 1, 9246952, 0, 0, 0, 0, 140737351959490, 1, 0, 0, 140737251616176, 12936662, 5, 140737488345664}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12559570, 
          var = 12507474, 
          chosen_clause = 140737488345104, 
          tag = 0x7fffffffd7c0, 
          next = 0x0
        }
#15 0x0000000000559a0b in top_level_1 (ignore=12507474) at keyboard.c:1355
No locals.
#16 0x00000000005f592e in internal_catch (tag=12555634, func=0x5599d3 <top_level_1>, arg=12507474) at eval.c:1202
        c = {
          tag = 12555634, 
          val = 12507474, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {5, 7988929332987547632, 4279008, 140737488346960, 0, 0, 7988929332960284656, -7988928721370886160}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6153582, 140737255104152, 4301629832, 0, 12507474, 12779824, 140737488345720, 60129542288, 12535520, 12033184, 6152158, 140737488345680, 12507474, 4279008, 140737488346960, 140737488345696}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#17 0x0000000000559939 in command_loop () at keyboard.c:1310
No locals.
#18 0x00000000005590df in recursive_edit_1 () at keyboard.c:940
        count = 1
        val = 5608104
#19 0x0000000000559292 in Frecursive_edit () at keyboard.c:1002
        count = 0
        buffer = 12507474
#20 0x00000000005575cc in main (argc=5, argv=0x7fffffffdf58) at emacs.c:1764
        dummy = 140737251592752
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 1
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x45 <Address 0x45 out of bounds>

Lisp Backtrace:
"apply" (0xffffc670)
"eval" (0xffffc888)
"command-line-1" (0xffffcd08)
"command-line" (0xffffd178)
"normal-top-level" (0xffffd530)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-15  7:37           ` Michal Sojka
@ 2010-08-16 17:40             ` Chong Yidong
  2010-08-16 20:39               ` Michal Sojka
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-08-16 17:40 UTC (permalink / raw)
  To: Michal Sojka; +Cc: 6214, Notmuch mailing list

Thanks, that is a useful backtrace.  Could you apply this patch and see
if it fixes the problem?


=== modified file 'src/eval.c'
*** src/eval.c	2010-08-06 19:07:16 +0000
--- src/eval.c	2010-08-16 17:37:22 +0000
***************
*** 2430,2437 ****
    register int i, numargs;
    register Lisp_Object spread_arg;
    register Lisp_Object *funcall_args;
!   Lisp_Object fun;
    struct gcpro gcpro1;
  
    fun = args [0];
    funcall_args = 0;
--- 2430,2438 ----
    register int i, numargs;
    register Lisp_Object spread_arg;
    register Lisp_Object *funcall_args;
!   Lisp_Object fun, retval;
    struct gcpro gcpro1;
+   USE_SAFE_ALLOCA;
  
    fun = args [0];
    funcall_args = 0;
***************
*** 2470,2477 ****
  	{
  	  /* Avoid making funcall cons up a yet another new vector of arguments
  	     by explicitly supplying nil's for optional values */
! 	  funcall_args = (Lisp_Object *) alloca ((1 + XSUBR (fun)->max_args)
! 						 * sizeof (Lisp_Object));
  	  for (i = numargs; i < XSUBR (fun)->max_args;)
  	    funcall_args[++i] = Qnil;
  	  GCPRO1 (*funcall_args);
--- 2471,2478 ----
  	{
  	  /* Avoid making funcall cons up a yet another new vector of arguments
  	     by explicitly supplying nil's for optional values */
! 	  SAFE_ALLOCA (funcall_args, Lisp_Object *, ((1 + XSUBR (fun)->max_args)
! 						     * sizeof (Lisp_Object)));
  	  for (i = numargs; i < XSUBR (fun)->max_args;)
  	    funcall_args[++i] = Qnil;
  	  GCPRO1 (*funcall_args);
***************
*** 2483,2490 ****
       function itself as well as its arguments.  */
    if (!funcall_args)
      {
!       funcall_args = (Lisp_Object *) alloca ((1 + numargs)
! 					     * sizeof (Lisp_Object));
        GCPRO1 (*funcall_args);
        gcpro1.nvars = 1 + numargs;
      }
--- 2484,2491 ----
       function itself as well as its arguments.  */
    if (!funcall_args)
      {
!       SAFE_ALLOCA (funcall_args, Lisp_Object *, ((1 + numargs)
! 						 * sizeof (Lisp_Object)));
        GCPRO1 (*funcall_args);
        gcpro1.nvars = 1 + numargs;
      }
***************
*** 2500,2506 ****
      }
  
    /* By convention, the caller needs to gcpro Ffuncall's args.  */
!   RETURN_UNGCPRO (Ffuncall (gcpro1.nvars, funcall_args));
  }
  \f
  /* Run hook variables in various ways.  */
--- 2501,2511 ----
      }
  
    /* By convention, the caller needs to gcpro Ffuncall's args.  */
!   retval = Ffuncall (gcpro1.nvars, funcall_args);
!   UNGCPRO;
!   SAFE_FREE ();
! 
!   return retval;
  }
  \f
  /* Run hook variables in various ways.  */

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-16 17:40             ` Chong Yidong
@ 2010-08-16 20:39               ` Michal Sojka
  2010-08-17 15:10                 ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Michal Sojka @ 2010-08-16 20:39 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 6214, Notmuch mailing list

On Mon, 16 Aug 2010, Chong Yidong wrote:
> Thanks, that is a useful backtrace.  Could you apply this patch and see
> if it fixes the problem?

Great! The patch fixes the problem. Now I can view 20 MB email in
notmuch.

Thanks,
Michal

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-16 20:39               ` Michal Sojka
@ 2010-08-17 15:10                 ` Chong Yidong
  2010-08-17 16:27                   ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-08-17 15:10 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 6214, Notmuch mailing list

Michal Sojka <sojkam1@fel.cvut.cz> writes:

> On Mon, 16 Aug 2010, Chong Yidong wrote:
>> Thanks, that is a useful backtrace.  Could you apply this patch and see
>> if it fixes the problem?
>
> Great! The patch fixes the problem. Now I can view 20 MB email in
> notmuch.

Hmm, there is a problem, though.  If we attempt to avoid a stack
overflow in `apply' by using the heap rather than the stack to store
large numbers of arguments, those arguments are invisible to the
stack-marking gargbage collector.

One workaround is to temporarily disable garbage collection if using the
heap.  Stefan, any ideas?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-17 15:10                 ` Chong Yidong
@ 2010-08-17 16:27                   ` Chong Yidong
  2010-08-17 20:57                     ` Andreas Schwab
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-08-17 16:27 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 6214, Notmuch mailing list

Chong Yidong <cyd@stupidchicken.com> writes:

> Hmm, there is a problem, though.  If we attempt to avoid a stack
> overflow in `apply' by using the heap rather than the stack to store
> large numbers of arguments, those arguments are invisible to the
> stack-marking gargbage collector.

Never mind, I got confused.  SAFE_ALLOCA uses record_unwind_protect, so
it's gc safe.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-17 16:27                   ` Chong Yidong
@ 2010-08-17 20:57                     ` Andreas Schwab
  2010-08-17 21:46                       ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Andreas Schwab @ 2010-08-17 20:57 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 6214, Notmuch mailing list, Stefan Monnier

Chong Yidong <cyd@stupidchicken.com> writes:

> Never mind, I got confused.  SAFE_ALLOCA uses record_unwind_protect, so
> it's gc safe.

No, it isn't.  SAFE_ALLOCA only protects the memory block, you need to
use SAVE_ALLOCA_LISP to protect also its contents.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: bug#6214: 23.1; json-read-string crashes emacs with long string
  2010-08-17 20:57                     ` Andreas Schwab
@ 2010-08-17 21:46                       ` Chong Yidong
  0 siblings, 0 replies; 13+ messages in thread
From: Chong Yidong @ 2010-08-17 21:46 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 6214, Notmuch mailing list, Stefan Monnier

Andreas Schwab <schwab@linux-m68k.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Never mind, I got confused.  SAFE_ALLOCA uses record_unwind_protect, so
>> it's gc safe.
>
> No, it isn't.  SAFE_ALLOCA only protects the memory block, you need to
> use SAVE_ALLOCA_LISP to protect also its contents.

Ah, OK.  Thanks.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2010-08-17 21:47 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-18 16:08 23.1; json-read-string crashes emacs with long string Carl Worth
2010-05-18 18:07 ` bug#6214: " Chong Yidong
2010-08-12 21:58   ` Michal Sojka
2010-08-13 16:37     ` Chong Yidong
2010-08-14  7:39       ` Michal Sojka
2010-08-14 21:30         ` Chong Yidong
2010-08-15  7:37           ` Michal Sojka
2010-08-16 17:40             ` Chong Yidong
2010-08-16 20:39               ` Michal Sojka
2010-08-17 15:10                 ` Chong Yidong
2010-08-17 16:27                   ` Chong Yidong
2010-08-17 20:57                     ` Andreas Schwab
2010-08-17 21:46                       ` Chong Yidong

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).