all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
To: emacs-devel@gnu.org
Subject: Re: Segfault in current bzr
Date: Mon, 27 Sep 2010 22:46:09 +0200	[thread overview]
Message-ID: <4CA10291.8090604@swipnet.se> (raw)
In-Reply-To: <m362xrlyo5.fsf@quimbies.gnus.org>

My bad, there was an FD_CLR missing.  Should be OK now.
BTW, don't say segfault when there is an abort.  They are two different 
classes of errors.

	Jan D.


Lars Magne Ingebrigtsen skrev 2010-09-27 22.27:
> Eli Zaretskii<eliz@gnu.org>  writes:
>
>> You can't really know, in an optimized build.  GCC is very good in
>> collapsing multiple calls to th same function into a single call.
>
> Right.  I've now rebuild with -O0, and I get this:
>
> #0  abort () at emacs.c:427
> #1  0x0000000000650cc4 in wait_reading_process_output (time_limit=-1,
>      microsecs=10000, read_kbd=0, do_display=0, wait_for_cell=12552578,
>      wait_proc=0x1f1c170, just_wait_proc=0) at process.c:4835
> #2  0x000000000064f29b in Faccept_process_output (process=0, seconds=27929479,
>      millisec=40, just_this_one=12552578) at process.c:4188
> #3  0x00000000005f7728 in Ffuncall (nargs=4, args=0x7fffffff9d00)
>      at eval.c:3000
> #4  0x0000000000643dff in Fbyte_code (bytestr=22447553, vector=23031829,
>      maxdepth=28) at bytecode.c:679
> #5  0x00000000005f7f9e in funcall_lambda (fun=23033477, nargs=1,
>      arg_vector=0x7fffffffa178) at eval.c:3174
> #6  0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa170)
>      at eval.c:3036
> #7  0x0000000000643dff in Fbyte_code (bytestr=26821025, vector=26823445,
>      maxdepth=20) at bytecode.c:679
> #8  0x00000000005f7f9e in funcall_lambda (fun=26823813, nargs=1,
>      arg_vector=0x7fffffffa5d8) at eval.c:3174
> #9  0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffa5d0)
>      at eval.c:3036
> #10 0x0000000000643dff in Fbyte_code (bytestr=25621713, vector=26649381,
>      maxdepth=24) at bytecode.c:679
> #11 0x00000000005f62dd in Feval (form=26251318) at eval.c:2358
> #12 0x00000000005f440f in internal_lisp_condition_case (var=13455794,
>      bodyform=26251318, handlers=26635814) at eval.c:1407
> #13 0x0000000000644db4 in Fbyte_code (bytestr=25610161, vector=26650277,
>      maxdepth=32) at bytecode.c:869
> #14 0x00000000005f7f9e in funcall_lambda (fun=26650853, nargs=3,
>      arg_vector=0x7fffffffb098) at eval.c:3174
> #15 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffb090)
>      at eval.c:3036
> #16 0x0000000000643dff in Fbyte_code (bytestr=26419153, vector=26702821,
>      maxdepth=20) at bytecode.c:679
> #17 0x00000000005f7f9e in funcall_lambda (fun=26703125, nargs=0,
>      arg_vector=0x7fffffffb508) at eval.c:3174
> #18 0x00000000005f78ad in Ffuncall (nargs=1, args=0x7fffffffb500)
>      at eval.c:3036
> #19 0x00000000005f6183 in Feval (form=26631350) at eval.c:2324
> #20 0x00000000005f440f in internal_lisp_condition_case (var=12552578,
>      bodyform=26631350, handlers=26631206) at eval.c:1407
> #21 0x0000000000644db4 in Fbyte_code (bytestr=25696769, vector=26664709,
>      maxdepth=16) at bytecode.c:869
> #22 0x00000000005f62dd in Feval (form=26632934) at eval.c:2358
> #23 0x00000000005f3f22 in internal_catch (tag=26381426, func=0x5f5c9a<Feval>,
>      arg=26632934) at eval.c:1204
> #24 0x0000000000644d13 in Fbyte_code (bytestr=25674961, vector=26664901,
>      maxdepth=12) at bytecode.c:854
> #25 0x00000000005f7f9e in funcall_lambda (fun=26665285, nargs=4,
>     arg_vector=0x7fffffffc258) at eval.c:3174
> #26 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc250)
>      at eval.c:3036
> #27 0x0000000000643dff in Fbyte_code (bytestr=26416897, vector=26703253,
>      maxdepth=20) at bytecode.c:679
> #28 0x00000000005f7f9e in funcall_lambda (fun=26703509, nargs=4,
>      arg_vector=0x7fffffffc6b8) at eval.c:3174
> #29 0x00000000005f78ad in Ffuncall (nargs=5, args=0x7fffffffc6b0)
>      at eval.c:3036
> #30 0x0000000000643dff in Fbyte_code (bytestr=24895585, vector=25204309,
>      maxdepth=20) at bytecode.c:679
> #31 0x00000000005f7f9e in funcall_lambda (fun=25204629, nargs=3,
>      arg_vector=0x7fffffffcb18) at eval.c:3174
> #32 0x00000000005f78ad in Ffuncall (nargs=4, args=0x7fffffffcb10)
>      at eval.c:3036
> #33 0x0000000000643dff in Fbyte_code (bytestr=26481233, vector=27489573,
>      maxdepth=24) at bytecode.c:679
> #34 0x00000000005f7f9e in funcall_lambda (fun=27490389, nargs=2,
>      arg_vector=0x7fffffffcf78) at eval.c:3174
> #35 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffcf70)
>      at eval.c:3036
> #36 0x0000000000643dff in Fbyte_code (bytestr=21560801, vector=26897077,
>      maxdepth=16) at bytecode.c:679
> #37 0x00000000005f7f9e in funcall_lambda (fun=26897845, nargs=2,
>      arg_vector=0x7fffffffd3c8) at eval.c:3174
> #38 0x00000000005f78ad in Ffuncall (nargs=3, args=0x7fffffffd3c0)
>      at eval.c:3036
> #39 0x0000000000643dff in Fbyte_code (bytestr=26149281, vector=26353765,
>      maxdepth=16) at bytecode.c:679
> #40 0x00000000005f7f9e in funcall_lambda (fun=26354197, nargs=1,
>      arg_vector=0x7fffffffd818) at eval.c:3174
> #41 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffd810)
>      at eval.c:3036
> #42 0x0000000000643dff in Fbyte_code (bytestr=26172961, vector=26355717,
>      maxdepth=28) at bytecode.c:679
> #43 0x00000000005f7f9e in funcall_lambda (fun=26356437, nargs=1,
>      arg_vector=0x7fffffffdcd8) at eval.c:3174
> #44 0x00000000005f78ad in Ffuncall (nargs=2, args=0x7fffffffdcd0)
>      at eval.c:3036
> #45 0x00000000005f1d85 in Fcall_interactively (function=24239010,
>      record_flag=12552578, keys=12598901) at callint.c:849
> #46 0x00000000005f76f5 in Ffuncall (nargs=4, args=0x7fffffffe050)
>      at eval.c:2996
> #47 0x00000000005f70a6 in call3 (fn=12739698, arg1=24239010, arg2=12552578,
>      arg3=12552578) at eval.c:2820
> #48 0x000000000056a320 in Fcommand_execute (cmd=24239010,
>      record_flag=12552578, keys=12552578, special=12552578) at keyboard.c:10326
> #49 0x0000000000558a36 in command_loop_1 () at keyboard.c:1737
> #50 0x00000000005f4585 in internal_condition_case (
>      bfun=0x558220<command_loop_1>, handlers=12604674,
>      hfun=0x557b28<cmd_error>) at eval.c:1460
> #51 0x0000000000557f21 in command_loop_2 (ignore=12552578) at keyboard.c:1338
> #52 0x00000000005f3f22 in internal_catch (tag=12600738,
>      func=0x557efb<command_loop_2>, arg=12552578) at eval.c:1204
> #53 0x0000000000557ed4 in command_loop () at keyboard.c:1317
> #54 0x000000000055765f in recursive_edit_1 () at keyboard.c:940
> #55 0x0000000000557812 in Frecursive_edit () at keyboard.c:1002
> #56 0x0000000000555b59 in main (argc=1, argv=0x7fffffffea58) at emacs.c:1712
>
> Lisp Backtrace:
> "accept-process-output" (0xffff9d08)
> "nnheader-accept-process-output" (0xffffa178)
> "nntp-accept-process-output" (0xffffa5d8)
> "byte-code" (0xffffa950)
> "nntp-send-command-and-decode" (0xffffb098)
> 0x1977515 PVEC_COMPILED
> "funcall" (0xffffb500)
> "byte-code" (0xffffbb70)
> "nntp-with-open-group-function" (0xffffc258)
> "nntp-request-article" (0xffffc6b8)
> "gnus-request-article" (0xffffcb18)
> "gnus-request-article-this-buffer" (0xffffcf78)
> "gnus-article-prepare" (0xffffd3c8)
> "gnus-summary-display-article" (0xffffd818)
> "gnus-summary-next-article" (0xffffdcd8)
> "call-interactively" (0xffffe058)
>
>



  parent reply	other threads:[~2010-09-27 20:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-27 19:56 Segfault in current bzr Lars Magne Ingebrigtsen
2010-09-27 19:59 ` Lars Magne Ingebrigtsen
2010-09-27 20:09   ` Lars Magne Ingebrigtsen
2010-09-27 20:14   ` Eli Zaretskii
2010-09-27 20:27     ` Lars Magne Ingebrigtsen
2010-09-27 20:37       ` Lars Magne Ingebrigtsen
2010-09-27 20:45         ` Lars Magne Ingebrigtsen
2010-09-27 20:46       ` Jan Djärv [this message]
2010-09-27 20:54         ` Lars Magne Ingebrigtsen
2010-09-27 22:29     ` David Kastrup
2010-09-27 20:16 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2010-09-28 11:10 grischka
2010-09-28 16:07 ` Eli Zaretskii
2010-09-28 17:19   ` grischka
2010-09-28 17:30     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CA10291.8090604@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.