bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

I can recreate this error in "emacs -Q" after evaluating the below and then
doing M-x list-packages.

=====

(require 'package)
(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)

=====

Here is the error I get:

=====

Importing package-keyring.gpg...done
error in process filter: End of file during parsing

=====

As an additional request (hopefully minor), can this process filter error
be improved to give more info as to which file caused it?


In GNU Emacs 25.0.93.10 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2016-05-02 built on
Repository revision: fd7b430afdd7ddea40cad7d231f634ff8bd536d8
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)

Configured using:
 'configure --with-modules
 --prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-25
 'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
 -I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
 'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
 -L/home/kmodi/usr_local/6/lib64 -ggdb3'
 PKG_CONFIG_PATH=/home/kmodi/usr_local/6/lib/pkgconfig:/home/kmodi/usr_local/6/lib64/pkgconfig:/cad/adi/apps/gnu/linux/x86_64/6/lib/pkgconfig:/cad/adi/apps/gnu/linux/x86_64/6/lib64/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig:/lib64/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  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 messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
current-kill: Kill ring is empty
Mark set
package
(("gnu" . "http://elpa.gnu.org/packages/") ("melpa" . "
http://melpa.org/packages/"))
Importing package-keyring.gpg...done
You can run the command ‘list-packages’ with M-x l-pac RET
error in process filter: End of file during parsing [2 times]
Mark set
next-line: End of buffer

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail mm-archive message dired
format-spec rfc822 mml mml-sec mailabbrev gmm-utils mailheader mm-decode
mm-bodies mm-encode url-handlers mail-utils network-stream nsm starttls
url-http tls gnutls mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw
url-cache url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs gnus-util mm-util help-fns mail-prsvr
password-cache url-vars mailcap epg finder-inf package epg-config seq
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 122628 13965)
 (symbols 48 25171 0)
 (miscs 40 49 166)
 (strings 32 27533 18874)
 (string-bytes 1 736436)
 (vectors 16 16284)
 (vector-slots 8 478740 15323)
 (floats 8 238 375)
 (intervals 56 2149 362)
 (buffers 976 12)
 (heap 1024 35960 2589))

-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 6856 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 15:19:02 +0000
> 
> I can recreate this error in "emacs -Q" after evaluating the below and then doing M-x list-packages.
> 
> =====
> 
> (require 'package)
> (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
> 
> =====
> 
> Here is the error I get:
> 
> =====
> 
> Importing package-keyring.gpg...done
> error in process filter: End of file during parsing
> 
> =====

Here's the problem: Emacs tries to read from an empty string, and
fails.  The backtrace is below.

> As an additional request (hopefully minor), can this process filter error be improved to give more info as to
> which file caused it?

Given the cause of the problem, how would you wish to improve the
error message?

  Thread 1 hit Breakpoint 3, Fsignal (error_symbol=20888, data=0) at eval.c:1471
  1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
  $44 = 20888
  $45 = (struct Lisp_Symbol *) 0x2b2ad00 <lispsym+20888>
  "end-of-file"
  (gdb) bt
  #0  Fsignal (error_symbol=20888, data=0) at eval.c:1471
  #1  0x0121cf5d in xsignal (error_symbol=20888, data=0) at eval.c:1577
  #2  0x0121cf9a in xsignal0 (error_symbol=20888) at eval.c:1586
  #3  0x01262e25 in end_of_file_error () at lread.c:1736
  #4  0x01267417 in read1 (readcharfun=-9223372036748765968, pch=0x82c3bc,
      first_in_list=false) at lread.c:3094
  #5  0x01264604 in read0 (readcharfun=-9223372036748765968) at lread.c:2137
  #6  0x01268c64 in read_list (flag=false, readcharfun=-9223372036748765968)
      at lread.c:3629
  #7  0x01265049 in read1 (readcharfun=-9223372036748765968, pch=0x82c70c,
      first_in_list=true) at lread.c:2484
  #8  0x01268a8e in read_list (flag=false, readcharfun=-9223372036748765968)
      at lread.c:3585
  #9  0x01265049 in read1 (readcharfun=-9223372036748765968, pch=0x82ca1c,
      first_in_list=false) at lread.c:2484
  #10 0x01268a8e in read_list (flag=true, readcharfun=-9223372036748765968)
      at lread.c:3585
  #11 0x012684f6 in read_vector (readcharfun=-9223372036748765968,
      bytecodeflag=false) at lread.c:3495
  #12 0x0126506e in read1 (readcharfun=-9223372036748765968, pch=0x82cdbc,
      first_in_list=false) at lread.c:2487
  #13 0x01264604 in read0 (readcharfun=-9223372036748765968) at lread.c:2137
  #14 0x01268c64 in read_list (flag=false, readcharfun=-9223372036748765968)
      at lread.c:3629
  #15 0x01265049 in read1 (readcharfun=-9223372036748765968, pch=0x82d10c,
      first_in_list=false) at lread.c:2484
  #16 0x01268a8e in read_list (flag=false, readcharfun=-9223372036748765968)
      at lread.c:3585
  #17 0x01265049 in read1 (readcharfun=-9223372036748765968, pch=0x82d41c,
      first_in_list=false) at lread.c:2484
  #18 0x01264604 in read0 (readcharfun=-9223372036748765968) at lread.c:2137
  #19 0x01264526 in read_internal_start (stream=-9223372036748765968, start=0,
      end=0) at lread.c:2110
  #20 0x0126427b in Fread_from_string (string=-9223372036748765968, start=0,
      end=0) at lread.c:2073
  #21 0x01221a0c in Ffuncall (nargs=2, args=0x82d698) at eval.c:2700
  #22 0x012826e1 in exec_byte_code (bytestr=-9223372036759330616,
      vector=-6917529027537623584, maxdepth=4611686018427387924,
      args_template=4611686018427388161, nargs=1, args=0x82de40)
      at bytecode.c:880
  #23 0x01222972 in funcall_lambda (fun=-6917529027537623184, nargs=1,
      arg_vector=0x82de38) at eval.c:2855
  #24 0x01221f3b in Ffuncall (nargs=2, args=0x82de30) at eval.c:2742
  #25 0x0122018e in Fapply (nargs=2, args=0x82de30) at eval.c:2278
  #26 0x0122180d in Ffuncall (nargs=3, args=0x82de28) at eval.c:2673
  #27 0x012826e1 in exec_byte_code (bytestr=-9223372036754479384,
      vector=-6917529027537762864, maxdepth=4611686018427387912,
      args_template=0, nargs=0, args=0x0) at bytecode.c:880
  #28 0x01222fd4 in funcall_lambda (fun=-6917529027537762616, nargs=0,
      arg_vector=0x82e400) at eval.c:2921
  #29 0x01221f3b in Ffuncall (nargs=1, args=0x82e3f8) at eval.c:2742
  #30 0x012826e1 in exec_byte_code (bytestr=-9223372036754478168,
      vector=-6917529027537762424, maxdepth=4611686018427387909,
      args_template=0, nargs=0, args=0x0) at bytecode.c:880
  #31 0x01222fd4 in funcall_lambda (fun=-6917529027537762152, nargs=2,
      arg_vector=0x82e9b0) at eval.c:2921
  #32 0x01221f3b in Ffuncall (nargs=3, args=0x82e9a8) at eval.c:2742
  #33 0x012826e1 in exec_byte_code (bytestr=-9223372036754110784,
      vector=-6917529027537760712, maxdepth=4611686018427387918,
      args_template=0, nargs=0, args=0x0) at bytecode.c:880
  #34 0x01222fd4 in funcall_lambda (fun=-6917529027537760416, nargs=2,
      arg_vector=0x82ef98) at eval.c:2921
  #35 0x01221f3b in Ffuncall (nargs=3, args=0x82ef90) at eval.c:2742
  #36 0x01220805 in Fapply (nargs=2, args=0x82f050) at eval.c:2321
  #37 0x01221047 in apply1 (fn=58089576, arg=-4611686018321073728)
      at eval.c:2537
  #38 0x012942bd in read_process_output_call (fun_and_args=-4611686018321073712)
      at process.c:5224
  #39 0x0121c61a in internal_condition_case_1 (
      bfun=0x12941d4 <read_process_output_call>, arg=-4611686018321073712,
      handlers=21168, hfun=0x1297822 <exec_sentinel_error_handler>)
      at eval.c:1333
  #40 0x01297ace in exec_sentinel (proc=-6917529027537622792,
      reason=-9223372036749244816) at process.c:6577
  #41 0x01297deb in status_notify (deleting_process=0x0, wait_proc=0x0)
      at process.c:6679
  #42 0x012929b0 in wait_reading_process_output (time_limit=30, nsecs=0,
      read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0,
      just_wait_proc=0) at process.c:4661
  #43 0x0101126c in sit_for (timeout=4611686018427387934, reading=true,
      display_option=1) at dispnew.c:5762
  #44 0x01158765 in read_char (commandflag=1, map=-4611686018321074016,
      prev_event=0, used_mouse_menu=0x82f62f, end_time=0x0) at keyboard.c:2706
  #45 0x0116cff6 in read_key_sequence (keybuf=0x82f7c0, bufsize=30, prompt=0,
      dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9055
  #46 0x01153df2 in command_loop_1 () at keyboard.c:1357
  #47 0x0121c56e in internal_condition_case (bfun=0x1153820 <command_loop_1>,
      handlers=21168, hfun=0x1152a9d <cmd_error>) at eval.c:1309
  #48 0x011532b7 in command_loop_2 (ignore=0) at keyboard.c:1099
  #49 0x0121b6eb in internal_catch (tag=56728, func=0x115327b <command_loop_2>,
      arg=0) at eval.c:1074
  #50 0x01153235 in command_loop () at keyboard.c:1078
  #51 0x011524ab in recursive_edit_1 () at keyboard.c:684
  #52 0x01152771 in Frecursive_edit () at keyboard.c:755
  #53 0x0114ff7b in main (argc=2, argv=0xa427e0) at emacs.c:1606

  Lisp Backtrace:
  "read-from-string" (0x82d6a0)
  0x62aa770 PVEC_COMPILED
  "apply" (0x82de30)
  "url-http-activate-callback" (0x82e400)
  "url-http-end-of-document-sentinel" (0x82e9b0)
  "url-http-async-sentinel" (0x82ef98)
  (gdb) frame 20
  #20 0x0126427b in Fread_from_string (string=-9223372036748765968, start=0,
      end=0) at lread.c:2073
  2073      ret = read_internal_start (string, start, end);
  (gdb) p string
  $46 = -9223372036748765968
  (gdb) xstring
  $47 = (struct Lisp_String *) 0x65194f0
  0

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Mon, 02 May 2016 15:19:02 +0000

>> As an additional request (hopefully minor), can this process filter error be improved to give more info as to
>> which file caused it?
>
> Given the cause of the problem, how would you wish to improve the
> error message?

I'd guess Kaushal (and I) were expecting package.el to handle the
error more graciously and verbosely.

Robert

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 02 May 2016 17:54:24 +0200
> 
> I'd guess Kaushal (and I) were expecting package.el to handle the
> error more graciously and verbosely.

As you see from the backtrace I posted, the problem is in url-http, not
in package.el.  Package simply starts a transaction that url-http
handles.

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

>
> Given the cause of the problem, how would you wish to improve the
> error message?
>
>   Thread 1 hit Breakpoint 3, Fsignal (error_symbol=20888, data=0) at
> eval.c:1471
>   1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
>   $44 = 20888
>   $45 = (struct Lisp_Symbol *) 0x2b2ad00 <lispsym+20888>
>   "end-of-file"
>   (gdb) bt
>   #0  Fsignal (error_symbol=20888, data=0) at eval.c:1471
>


>   Lisp Backtrace:
>   "read-from-string" (0x82d6a0)
>   0x62aa770 PVEC_COMPILED
>   "apply" (0x82de30)
>   "url-http-activate-callback" (0x82e400)
>   "url-http-end-of-document-sentinel" (0x82e9b0)
>   "url-http-async-sentinel" (0x82ef98)
>   (gdb) frame 20
>   #20 0x0126427b in Fread_from_string (string=-9223372036748765968,
> start=0,
>       end=0) at lread.c:2073
>   2073      ret = read_internal_start (string, start, end);
>   (gdb) p string
>   $46 = -9223372036748765968
>   (gdb) xstring
>   $47 = (struct Lisp_String *) 0x65194f0
>   0
>

Hi Eli, I don't have C coding experience to be able to provide an answer
that makes sense or is practically possible. I was just curious to know if
it were possible to add more info to the process sentinel error message..

So here's my try at a suggestion on how that error message could possible
be improved:

For instance.. an action to fetch an XYZ url was started. But for whatever
reason (like empty string detection), that XYZ url fetch action was
incomplete. So may be the error said: Unable to fetch XYZ url (instead of
providing the lower level error of empty string to the user).

But then again, how do we define what's upper level and what's lower level
error? :)

I aim to just brain-storm on possible error message improvement. Hope this
helps.

Thanks for replicating the error in gdb. Without you paraphrasing what that
backtrace meant, I wouldn't have known what to make out of that long
backtrace.

I tried a brief attempt at recreating the same, but it didn't work.. I got
the "error in process filter" to happen in emacs, but the gdb interface
just showed this:

=====

Temporary breakpoint 2 at 0x578c80: file sysdep.c, line 915.
(gdb) r -Q
Starting program: /home/kmodi/downloads/git/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffed75f700 (LWP 9860)]

(emacs:9848): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

break Fsignal

bt

=====

I was expecting the (gdb) prompt to show up where I could type "break
Fsignal" (I am assuming that's how you set breakpoint at Fsignal?). But it
didn't.. looks like that prompt was lost after "GLib-GIO-CRITICAL **:
g_settings_schema_source_lookup: assertion 'source != NULL' failed" showed
up.

( I am totally exposing my level of experience with gdb and C debug with
that :))
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3999 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

Sorry, I figured out my mistake (with respect to be unable to set
breakpoint). It's still not working smoothly.. the breakpoint is activated
with each character I type.. so not sure what's up.

As you already have the debug info, I will put learning gdb on my short
term to-learn list.

Thanks.

=====
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :1.0
TERM = xterm-256color
Breakpoint 1 at 0x555e7d: file emacs.c, line 354.
Temporary breakpoint 2 at 0x578c80: file sysdep.c, line 915.
(gdb) break Fsignal
Breakpoint 3 at 0x5f338c: file eval.c, line 1471.
(gdb) bt
No stack.
(gdb) r -Q
Starting program: /home/kmodi/downloads/git/emacs/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffed75f700 (LWP 27555)]

(emacs:27551): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

Breakpoint 3, Fsignal (error_symbol=41328, data=16757379) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) c
Continuing.

Breakpoint 3, Fsignal (error_symbol=41328, data=14850531) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) c
Continuing.

Breakpoint 3, Fsignal (error_symbol=41328, data=25212659) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) c
Continuing.

Breakpoint 3, Fsignal (error_symbol=41328, data=25415251) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2151 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

Looks like, some minor mode keeps on checking for balanced parentheses and
throws errors as I type "(require 'package)" after "r -Q" in gdb.

Is that expected? If so, what do you need to disable to prevent these false
breakpoints?

Thanks.

Here's a backtrace for that:

(emacs:38938): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

Breakpoint 3, Fsignal (error_symbol=41328, data=14842835) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) bt
#0  Fsignal (error_symbol=41328, data=14842835) at eval.c:1471
#1  0x00000000005f3742 in xsignal (error_symbol=41328, data=14842835) at
eval.c:1577
#2  0x00000000005f3817 in xsignal3 (error_symbol=41328, arg1=18570180,
arg2=586, arg3=586) at eval.c:1604
#3  0x0000000000636545 in scan_lists (from=146, count=-1, depth=-1,
sexpflag=true) at syntax.c:2947
#4  0x0000000000636e34 in Fscan_sexps (from=590, count=-2) at syntax.c:3076
#5  0x00000000005f631a in Ffuncall (nargs=3, args=0x7fffffff64b0) at
eval.c:2696
#6  0x000000000063c073 in exec_byte_code (bytestr=11043980,
vector=11044013, maxdepth=18, args_template=1026, nargs=1,
args=0x7fffffff6a00) at bytecode.c:880
#7  0x00000000005f6b6c in funcall_lambda (fun=11043925, nargs=1,
arg_vector=0x7fffffff69f8) at eval.c:2855
#8  0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff69f0) at
eval.c:2742
#9  0x000000000063c073 in exec_byte_code (bytestr=11111676,
vector=11111709, maxdepth=22, args_template=2, nargs=0,
args=0x7fffffff6f10) at bytecode.c:880
#10 0x00000000005f6b6c in funcall_lambda (fun=11111637, nargs=0,
arg_vector=0x7fffffff6f10) at eval.c:2855
#11 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff6f08) at
eval.c:2742
#12 0x000000000063c073 in exec_byte_code (bytestr=11111564,
vector=11111597, maxdepth=14, args_template=2, nargs=0,
args=0x7fffffff7438) at bytecode.c:880
#13 0x00000000005f6b6c in funcall_lambda (fun=11111525, nargs=0,
arg_vector=0x7fffffff7438) at eval.c:2855
#14 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff7430) at
eval.c:2742
#15 0x000000000063c073 in exec_byte_code (bytestr=11109500,
vector=11109533, maxdepth=22, args_template=2, nargs=0,
args=0x7fffffff7ab0) at bytecode.c:880
#16 0x00000000005f6b6c in funcall_lambda (fun=11109453, nargs=0,
arg_vector=0x7fffffff7ab0) at eval.c:2855
#17 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff7aa8) at
eval.c:2742
#18 0x00000000005f5220 in Fapply (nargs=2, args=0x7fffffff7aa8) at
eval.c:2274
#19 0x00000000005f61e8 in Ffuncall (nargs=3, args=0x7fffffff7aa0) at
eval.c:2673
#20 0x000000000063c073 in exec_byte_code (bytestr=17759172,
vector=18920261, maxdepth=18, args_template=514, nargs=0,
args=0x7fffffff7fd8) at bytecode.c:880
#21 0x00000000005f6b6c in funcall_lambda (fun=19745725, nargs=0,
arg_vector=0x7fffffff7fd8) at eval.c:2855
#22 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff7fd0) at
eval.c:2742
#23 0x000000000063c073 in exec_byte_code (bytestr=11361660,
vector=11361693, maxdepth=18, args_template=2, nargs=0,
args=0x7fffffff8500) at bytecode.c:880
#24 0x00000000005f6b6c in funcall_lambda (fun=11361621, nargs=0,
arg_vector=0x7fffffff8500) at eval.c:2855
#25 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff84f8) at
eval.c:2742
#26 0x000000000063c073 in exec_byte_code (bytestr=11360308,
vector=11360341, maxdepth=10, args_template=2, nargs=0,
args=0x7fffffff8b68) at bytecode.c:880
#27 0x00000000005f6b6c in funcall_lambda (fun=11360269, nargs=0,
arg_vector=0x7fffffff8b68) at eval.c:2855
#28 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff8b60) at
eval.c:2742
#29 0x00000000005f5220 in Fapply (nargs=2, args=0x7fffffff8b60) at
eval.c:2274
#30 0x00000000005f61e8 in Ffuncall (nargs=3, args=0x7fffffff8b58) at
eval.c:2673
#31 0x000000000063c073 in exec_byte_code (bytestr=10909844,
vector=10909877, maxdepth=30, args_template=0, nargs=0, args=0x0) at
bytecode.c:880
#32 0x00000000005f6ea8 in funcall_lambda (fun=10909797, nargs=1,
arg_vector=0xa678b5 <pure+1394613>) at eval.c:2921
#33 0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff90a0) at
eval.c:2742
#34 0x00000000005f5d10 in call1 (fn=45648, arg1=20350077) at eval.c:2552
#35 0x0000000000561100 in timer_check_2 (timers=14843027,
idle_timers=14842995) at keyboard.c:4419
#36 0x000000000056122e in timer_check () at keyboard.c:4481
#37 0x000000000055f0c6 in readable_events (flags=1) at keyboard.c:3320
#38 0x0000000000565979 in get_input_pending (flags=1) at keyboard.c:6717
#39 0x000000000056bab1 in detect_input_pending_run_timers (do_display=true)
at keyboard.c:9854
#40 0x0000000000649b14 in wait_reading_process_output (time_limit=30,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=0, wait_proc=0x0,
just_wait_proc=0) at process.c:4950
#41 0x00000000004266ef in sit_for (timeout=122, reading=true,
display_option=1) at dispnew.c:5762
#42 0x000000000055d9b3 in read_char (commandflag=1, map=14847235,
prev_event=0, used_mouse_menu=0x7fffffff9a1f, end_time=0x0) at
keyboard.c:2706
#43 0x000000000056a2d9 in read_key_sequence (keybuf=0x7fffffff9bd0,
bufsize=30, prompt=0, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true,
prevent_redisplay=false) at keyboard.c:9055
#44 0x000000000055a8a9 in command_loop_1 () at keyboard.c:1357
#45 0x00000000005f2f86 in internal_condition_case (bfun=0x55a49f
<command_loop_1>, handlers=19056, hfun=0x559c89 <cmd_error>) at eval.c:1309
#46 0x000000000055a1a7 in command_loop_2 (ignore=0) at keyboard.c:1099
#47 0x00000000005f28a6 in internal_catch (tag=46224, func=0x55a17e
<command_loop_2>, arg=0) at eval.c:1074
#48 0x000000000055a147 in command_loop () at keyboard.c:1078
#49 0x0000000000559858 in recursive_edit_1 () at keyboard.c:684
#50 0x00000000005599eb in Frecursive_edit () at keyboard.c:755
#51 0x00000000005578aa in main (argc=2, argv=0x7fffffffa068) at emacs.c:1606

Lisp Backtrace:
"scan-sexps" (0xffff64b8)
"forward-sexp" (0xffff69f8)
"elisp--beginning-of-sexp" (0xffff6f10)
"elisp--fnsym-in-current-sexp" (0xffff7438)
"elisp-eldoc-documentation-function" (0xffff7ab0)
"apply" (0xffff7aa8)
0x12d4bb8 PVEC_COMPILED
"eldoc-print-current-symbol-info" (0xffff8500)
0xad5808 PVEC_COMPILED
"apply" (0xffff8b60)
"timer-event-handler" (0xffff90a8)

On Mon, May 2, 2016 at 12:41 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Sorry, I figured out my mistake (with respect to be unable to set
> breakpoint). It's still not working smoothly.. the breakpoint is activated
> with each character I type.. so not sure what's up.
>
> As you already have the debug info, I will put learning gdb on my short
> term to-learn list.
>
> Thanks.
>
> =====
> Are you sure you want to change it? (y or n) [answered Y; input not from
> terminal]
> DISPLAY = :1.0
> TERM = xterm-256color
> Breakpoint 1 at 0x555e7d: file emacs.c, line 354.
> Temporary breakpoint 2 at 0x578c80: file sysdep.c, line 915.
> (gdb) break Fsignal
> Breakpoint 3 at 0x5f338c: file eval.c, line 1471.
> (gdb) bt
> No stack.
> (gdb) r -Q
> Starting program: /home/kmodi/downloads/git/emacs/src/emacs -Q
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [New Thread 0x7fffed75f700 (LWP 27555)]
>
> (emacs:27551): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
> assertion 'source != NULL' failed
>
> Breakpoint 3, Fsignal (error_symbol=41328, data=16757379) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
>
> Breakpoint 3, Fsignal (error_symbol=41328, data=14850531) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
>
> Breakpoint 3, Fsignal (error_symbol=41328, data=25212659) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
>
> Breakpoint 3, Fsignal (error_symbol=41328, data=25415251) at eval.c:1471
> 1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> --
>
> --
> Kaushal Modi
>
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 10191 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 16:41:32 +0000
> Cc: 23424@debbugs.gnu.org
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=16757379) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=14850531) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=25212659) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=41328, data=25415251) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);

This is your "Debugging Emacs 101", lesson 1:

A breakpoint in Fsignal is frequently hit because some error is thrown
which Emacs will catch and ignore, but the debugger gets to see it
first.  To see whether this is the signal you are after (if you don't
already know), do this:

  (gdb) p error_symbol
  (gdb) xsymbol

The last command should display the Lisp name of the signal.  Crystal
ball here says you will see "void-variable", which is not the signal
you want.  So now make the breakpoint conditional:

  (gdb) condition 3 error_symbol != 41328
  (gdb) c

and see what other signal is thrown.  I had a couple of other
unrelated signals (which happened once each, so I didn't feel like
making the condition more complex), and finally you will get your
expected "end-of-file" error.  Then look around; the Lisp backtrace
should be the first thing to look at.

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

>
> This is your "Debugging Emacs 101", lesson 1:
>
> A breakpoint in Fsignal is frequently hit because some error is thrown
> which Emacs will catch and ignore, but the debugger gets to see it
> first.  To see whether this is the signal you are after (if you don't
> already know), do this:
>
>   (gdb) p error_symbol
>   (gdb) xsymbol
>
> The last command should display the Lisp name of the signal.  Crystal
> ball here says you will see "void-variable", which is not the signal
> you want.  So now make the breakpoint conditional:
>
>   (gdb) condition 3 error_symbol != 41328
>   (gdb) c
>
> and see what other signal is thrown.  I had a couple of other
> unrelated signals (which happened once each, so I didn't feel like
> making the condition more complex), and finally you will get your
> expected "end-of-file" error.  Then look around; the Lisp backtrace
> should be the first thing to look at.
>

Thanks for that quick intro to setting conditional breakpoints.

 I did

(gdb) condition 3 error_symbol!=<num1> && error_symbol!=<num2> && ..

and looks like that worked.

But it looks like I have a different backtrace than the one you got.

(gdb) p error_symbol
$3 = 49824
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0xc87bd0 <lispsym+49824>
"void-variable"
(gdb) condition 3 error_symbol!=41328 && error_symbol!=49824
(gdb) c
Continuing.

Breakpoint 3, Fsignal (error_symbol=19056, data=16197139) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) p error_symbol
$5 = 19056
(gdb) xsymbol
$6 = (struct Lisp_Symbol *) 0xc803a0 <lispsym+19056>
"error"
(gdb) bt
#0  Fsignal (error_symbol=19056, data=16197139) at eval.c:1471
#1  0x00000000005f631a in Ffuncall (nargs=3, args=0x7fffffff6430) at
eval.c:2696
#2  0x000000000063c073 in exec_byte_code (bytestr=9618644, vector=9618677,
maxdepth=26, args_template=514, nargs=2, args=0x7fffffff6970) at
bytecode.c:880
#3  0x00000000005f6b6c in funcall_lambda (fun=9618597, nargs=2,
arg_vector=0x7fffffff6970) at eval.c:2855
#4  0x00000000005f6568 in Ffuncall (nargs=3, args=0x7fffffff6968) at
eval.c:2742
#5  0x000000000063c073 in exec_byte_code (bytestr=26216724,
vector=26182181, maxdepth=18, args_template=0, nargs=0, args=0x0) at
bytecode.c:880
#6  0x00000000005f6ea8 in funcall_lambda (fun=26182285, nargs=2,
arg_vector=0x18f8225) at eval.c:2921
#7  0x00000000005f6568 in Ffuncall (nargs=3, args=0x7fffffff6e98) at
eval.c:2742
#8  0x000000000063c073 in exec_byte_code (bytestr=26203300,
vector=26180981, maxdepth=22, args_template=0, nargs=0, args=0x0) at
bytecode.c:880
#9  0x00000000005f6ea8 in funcall_lambda (fun=26181189, nargs=1,
arg_vector=0x18f7d75) at eval.c:2921
#10 0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff73d8) at
eval.c:2742
#11 0x000000000063c073 in exec_byte_code (bytestr=25712436,
vector=20655013, maxdepth=26, args_template=1026, nargs=1,
args=0x7fffffff7918) at bytecode.c:880
#12 0x00000000005f6b6c in funcall_lambda (fun=24354509, nargs=1,
arg_vector=0x7fffffff7910) at eval.c:2855
#13 0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff7908) at
eval.c:2742
#14 0x000000000063c073 in exec_byte_code (bytestr=17397476,
vector=21453909, maxdepth=10, args_template=2, nargs=0,
args=0x7fffffff7e40) at bytecode.c:880
#15 0x00000000005f6b6c in funcall_lambda (fun=20671589, nargs=0,
arg_vector=0x7fffffff7e40) at eval.c:2855
#16 0x00000000005f6568 in Ffuncall (nargs=1, args=0x7fffffff7e38) at
eval.c:2742
#17 0x000000000063c073 in exec_byte_code (bytestr=14902196,
vector=21523493, maxdepth=22, args_template=1026, nargs=1,
args=0x7fffffff8448) at bytecode.c:880
#18 0x00000000005f6b6c in funcall_lambda (fun=21523645, nargs=1,
arg_vector=0x7fffffff8440) at eval.c:2855
#19 0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff8438) at
eval.c:2742
#20 0x00000000005ee638 in Ffuncall_interactively (nargs=2,
args=0x7fffffff8438) at callint.c:252
#21 0x00000000005f61e8 in Ffuncall (nargs=3, args=0x7fffffff8430) at
eval.c:2673
#22 0x00000000005f09be in Fcall_interactively (function=5444288,
record_flag=5289200, keys=13400757) at callint.c:840
#23 0x00000000005f6355 in Ffuncall (nargs=4, args=0x7fffffff8758) at
eval.c:2700
#24 0x000000000063c073 in exec_byte_code (bytestr=10409484,
vector=10409517, maxdepth=54, args_template=4102, nargs=2,
args=0x7fffffff8cd8) at bytecode.c:880
#25 0x00000000005f6b6c in funcall_lambda (fun=10409437, nargs=2,
arg_vector=0x7fffffff8cc8) at eval.c:2855
#26 0x00000000005f6568 in Ffuncall (nargs=3, args=0x7fffffff8cc0) at
eval.c:2742
#27 0x000000000063c073 in exec_byte_code (bytestr=10408684,
vector=10408717, maxdepth=62, args_template=3078, nargs=3,
args=0x7fffffff9318) at bytecode.c:880
#28 0x00000000005f6b6c in funcall_lambda (fun=10408629, nargs=3,
arg_vector=0x7fffffff9300) at eval.c:2855
#29 0x00000000005f6568 in Ffuncall (nargs=4, args=0x7fffffff92f8) at
eval.c:2742
#30 0x00000000005ee638 in Ffuncall_interactively (nargs=4,
args=0x7fffffff92f8) at callint.c:252
#31 0x00000000005f61e8 in Ffuncall (nargs=5, args=0x7fffffff92f0) at
eval.c:2673
#32 0x00000000005f576f in Fapply (nargs=3, args=0x7fffffff93e0) at
eval.c:2321
#33 0x00000000005eeab0 in Fcall_interactively (function=560928,
record_flag=0, keys=13400757) at callint.c:389
#34 0x00000000005f6355 in Ffuncall (nargs=4, args=0x7fffffff9668) at
eval.c:2700
#35 0x000000000063c073 in exec_byte_code (bytestr=10409484,
vector=10409517, maxdepth=54, args_template=4102, nargs=1,
args=0x7fffffff9bc0) at bytecode.c:880
#36 0x00000000005f6b6c in funcall_lambda (fun=10409437, nargs=1,
arg_vector=0x7fffffff9bb8) at eval.c:2855
#37 0x00000000005f6568 in Ffuncall (nargs=2, args=0x7fffffff9bb0) at
eval.c:2742
#38 0x00000000005f5d10 in call1 (fn=14784, arg1=560928) at eval.c:2552
#39 0x000000000055ac58 in command_loop_1 () at keyboard.c:1471
#40 0x00000000005f2f86 in internal_condition_case (bfun=0x55a49f
<command_loop_1>, handlers=19056, hfun=0x559c89 <cmd_error>) at eval.c:1309
#41 0x000000000055a1a7 in command_loop_2 (ignore=0) at keyboard.c:1099
#42 0x00000000005f28a6 in internal_catch (tag=46224, func=0x55a17e
<command_loop_2>, arg=0) at eval.c:1074
#43 0x000000000055a147 in command_loop () at keyboard.c:1078
#44 0x0000000000559858 in recursive_edit_1 () at keyboard.c:684
#45 0x00000000005599eb in Frecursive_edit () at keyboard.c:755
#46 0x00000000005578aa in main (argc=2, argv=0x7fffffffa068) at emacs.c:1606

Lisp Backtrace:
"signal" (0xffff6438)
"error" (0xffff6970)
"epg-check-configuration" (0xffff6ea0)
"epg-find-configuration" (0xffff73e0)
"package-refresh-contents" (0xffff7910)
"package-menu-refresh" (0xffff7e40)
"list-packages" (0xffff8440)
"funcall-interactively" (0xffff8438)
"call-interactively" (0xffff8760)
"command-execute" (0xffff8cc8)
"execute-extended-command" (0xffff9300)
"funcall-interactively" (0xffff92f8)
"call-interactively" (0xffff9670)
"command-execute" (0xffff9bb8)
(gdb)

-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 8736 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 17:22:05 +0000
> Cc: 23424@debbugs.gnu.org
> 
> But it looks like I have a different backtrace than the one you got.
> 
> (gdb) p error_symbol
> $3 = 49824
> (gdb) xsymbol
> $4 = (struct Lisp_Symbol *) 0xc87bd0 <lispsym+49824>
> "void-variable"
> (gdb) condition 3 error_symbol!=41328 && error_symbol!=49824
> (gdb) c
> Continuing.
> 
> Breakpoint 3, Fsignal (error_symbol=19056, data=16197139) at eval.c:1471
> 1471 = (NILP (error_symbol) ? Fcar (data) : error_symbol);
> (gdb) p error_symbol
> $5 = 19056
> (gdb) xsymbol
> $6 = (struct Lisp_Symbol *) 0xc803a0 <lispsym+19056>
> "error"

That's not the error you are after.  Keep going.  (You get this
because you have epg installed, whereas I don't.)

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

>
> That's not the error you are after.  Keep going.  (You get this
> because you have epg installed, whereas I don't.)
>

FYI, the melpa issue is fixed. But evaluating the below in "emacs -Q"
recreates the same "end of file" error.

(progn
  (setq package-archives '(("melpa-fake" . "
https://gist.githubusercontent.com/kaushalmodi/0603d601d84fc3282a34f08d3fe75f30/raw/597a359fba08dac61ff20e1ece6437b406a5a622/
")))
  (call-interactively #'list-packages))

I basically took the valid archive-contents file and truncated few
characters from the end of it:
https://gist.githubusercontent.com/kaushalmodi/0603d601d84fc3282a34f08d3fe75f30/raw/597a359fba08dac61ff20e1ece6437b406a5a622/archive-contents

-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1444 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

I have a followup gdb 101 question:

I thought I would improve the debug capability by adding the flags
"--enable-checking='yes,glyphs' --enable-check-lisp-object-type" to
./configure as per etc/DEBUG. I did not have those 2 flags earlier. But
after rebuilding using the suggested options, the conditional breakpoints
do not work. I also noticed that earlier "p error_symbol" gave something
like,

$1 = 41328

Now it gives something like,

$1 = {
  i = 41328
}

Also, when earlier I saw:

    Breakpoint 3, Fsignal (error_symbol=19056, data=16197139) at eval.c:1471

, now I see instead:

    Breakpoint 3, Fsignal (error_symbol=..., data=...) at eval.c:1471

(those numbers for error_symbol and data are literally replaced with "...")

=====

(emacs:22439): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

Breakpoint 3, Fsignal (error_symbol=..., data=...) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);
(gdb) p error_symbol
$1 = {
  i = 41328
}
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0xdc3ee0 <lispsym+41328>
"scan-error"
(gdb) condition 3 error_symbol!=41328
(gdb) c
Continuing.
Error in testing breakpoint condition:
Structure has no component named operator!=.
Error in testing breakpoint condition:
Structure has no component named operator!=.

Breakpoint 3, Fsignal (error_symbol=..., data=...) at eval.c:1471
1471        = (NILP (error_symbol) ? Fcar (data) : error_symbol);

Here's my new ./configure command:

./configure options:
  --with-modules --prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-25
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CPPFLAGS=-fgnu89-inline -I/home/kmodi/usr_local/6/include
-I/usr/include/freetype2 -I/usr/include' 'CFLAGS=-ggdb3 -O0'
'CXXFLAGS=-ggdb3 -O0' 'LDFLAGS=-L/home/kmodi/usr_local/6/lib
-L/home/kmodi/usr_local/6/lib64 -ggdb3'
PKG_CONFIG_PATH=/home/kmodi/usr_local/6/lib/pkgconfig:/home/kmodi/usr_local/6/lib64/pkgconfig:/cad/adi/apps/gnu/linux/x86_64/6/lib/pkgconfig:/cad/adi/apps/gnu/linux/x86_64/6/lib64/pkgconfig:/usr/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig:/lib64/pkgconfig

For now, I will rebuild emacs without "--enable-checking='yes,glyphs'
--enable-check-lisp-object-type". But it would be good to know why those
flags affected gdb (when etc/DEBUG says that those should not), and also
why didn't conditional breakpoints work in this case. (I hope to get the
old conditional-breakpoint-working-self back once I finish rebuilding
without those flags.)
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3893 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Kaushal Modi]

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

I was finally able to get the backtrace for end-of-file after rebuilding
emacs without those 2 assertion check flags.

>
So the last elisp-land function to propagate the error was in url-http.el:

=====
(defun url-http-activate-callback ()
  "Activate callback specified when this buffer was created."
  (url-http-mark-connection-as-free (url-host url-current-object)
   (url-port url-current-object)
   url-http-process)
  (url-http-debug "Activating callback in buffer (%s): %S %S"
 (buffer-name) url-callback-function url-callback-arguments)
  (apply url-callback-function url-callback-arguments))
=====

I see that url-http-debug form but it is not run because the error appears
too soon and the user does not have change to hit C-g to make the info
print in url-http-debug. So how about printing that info if "(apply
url-callback-function url-callback-arguments)" results in error?

With the above "melpa-fake" archive from my gist.github.com and a modified
version of url-http-activate-callback as below:

=====
(defun url-http-activate-callback ()
  "Activate callback specified when this buffer was created."
  (url-http-mark-connection-as-free (url-host url-current-object)
   (url-port url-current-object)
   url-http-process)
  (url-http-debug "Activating callback in buffer (%s): %S %S"
 (buffer-name) url-callback-function url-callback-arguments)
  (message "url-callback-function: %S" url-callback-function)
  (apply url-callback-function url-callback-arguments))
=====

I get:

=====
url-callback-function: #[257 <byte-code> [("melpa-fake" . "
https://gist.githubusercontent.com/kaushalmodi/0603d601d84fc3282a34f08d3fe75f30/raw/597a359fba08dac61ff20e1ece6437b406a5a622/")
"archive-contents" t "
https://gist.githubusercontent.com/kaushalmodi/0603d601d84fc3282a34f08d3fe75f30/raw/597a359fba08dac61ff20e1ece6437b406a5a622/archive-contents"
package-user-dir package-check-signature require url-handlers
generate-new-buffer " *temp*" make-byte-code 0 <byte-code> vconcat vector
[buffer-name kill-buffer] 2 (error) plist-get :error error "Error
retrieving: %s %S" search-forward-regexp "^
?

?" nil noerror "incomprehensible buffer" url-insert-buffer-contents
kill-buffer t package--update-downloads-in-progress signal buffer-string
expand-file-name format "archives/%s" read-from-string make-directory
write-region silent package--check-signature 256 <byte-code> [write-region
nil silent mapconcat epg-signature-to-string "
" ".signed"] 7 "

(fn &optional GOOD-SIGS)" "\301\300!\207"
[package--update-downloads-in-progress] package-unsigned-archives] 20 "

(fn STATUS)"]
error in process filter: End of file during parsing [2 times]
=====

So can we have something like:
- If  (apply url-callback-function url-callback-arguments) returns an
error, then extract the url being fetched from url-callback-function and
print some like "Error incurred when when processing XYZ url.". In this
case, we know that read-from-string threw an error. So we can even say that
the string fetched from XYZ url could not be parsed as a valid lisp form
(it does not necessarily mean that it read an empty string; in this case
the lisp form was incomplete).

The value of url-callback-function has a lot of other info which I do not
understand (I spy mainly the URL in it and "read-from-string" in it). But
may be using all the info in that var, we can have a well constructed error
message that can tell us what exactly went wrong. What do you think?
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 5740 bytes --]

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 23:18:38 +0000
> Cc: 23424@debbugs.gnu.org
> 
> So can we have something like:
> - If (apply url-callback-function url-callback-arguments) returns an error, then extract the url being fetched from
> url-callback-function and print some like "Error incurred when when processing XYZ url.". In this case, we
> know that read-from-string threw an error. So we can even say that the string fetched from XYZ url could not
> be parsed as a valid lisp form (it does not necessarily mean that it read an empty string; in this case the lisp
> form was incomplete). 

Can you propose a patch?

> The value of url-callback-function has a lot of other info which I do not understand (I spy mainly the URL in it
> and "read-from-string" in it). But may be using all the info in that var, we can have a well constructed error
> message that can tell us what exactly went wrong. What do you think? 

I know almost nothing about that code, perhaps someone else could
answer.

bug#23424: 25.0.93; error in process sentinel with Melpa added to package-archives

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 22:05:50 +0000
> Cc: 23424@debbugs.gnu.org
> 
> I have a followup gdb 101 question:
> 
> I thought I would improve the debug capability by adding the flags "--enable-checking='yes,glyphs'
> --enable-check-lisp-object-type" to ./configure as per etc/DEBUG. I did not have those 2 flags earlier. But after
> rebuilding using the suggested options, the conditional breakpoints do not work. I also noticed that earlier "p
> error_symbol" gave something like,
> 
> $1 = 41328
> 
> Now it gives something like,
> 
> $1 = {
> i = 41328
> }

The --enable-check-lisp-object-type changes the representation of Lisp
objects, so that they are no longer represented by C integers.
Instead, they are represented by a structure with a single integer
member.  From src/lisp.h:

  #ifdef CHECK_LISP_OBJECT_TYPE

  typedef struct { EMACS_INT i; } Lisp_Object;
  [...]
  #else /* CHECK_LISP_OBJECT_TYPE */
  [...]

  typedef EMACS_INT Lisp_Object;

  #endif

So instead of

  (gdb) condition 3 error_symbol != 41328

you should say something like

  (gdb) condition 3 error_symbol.i != 41328

> Also, when earlier I saw:
> 
> Breakpoint 3, Fsignal (error_symbol=19056, data=16197139) at eval.c:1471
> 
> , now I see instead:
> 
> Breakpoint 3, Fsignal (error_symbol=..., data=...) at eval.c:1471
> 
> (those numbers for error_symbol and data are literally replaced with "...")

By default, GDB doesn't display non-scalar arguments to functions when
it shows stack frames.  It displays ellipses for any non-scalar
argument.  You can change that with

  (gdb) set print frame-arguments all

Or just type

  (gdb) p error_symbol

etc. for any argument whose value you want to see; the ellipsis only
affects the values of arguments in frame display.

As yet another alternative, you can ask GDB to do that automatically
when it stops at a breakpoint:

  (gdb) commands 3
   > p error_symbol
   > xsymbol
   > end

And that concludes your lesson #2.  Reading the relevant sections of
the GDB manual is optional; suggested reading:

  (info "(gdb) Print Settings")
  (info "(gdb) Break Commands")