Emacs aborts during byte-compilation from Dired

Emacs aborts during byte-compilation from Dired

[Romain Francoise]

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

Hi,

I received this report from a Debian user:

| The latest emacs-snapshot aborts if I try to compile Fontifier.el
| from the mozart package.
|
| I am compiling it from dired (typing B on the line with Fontifier.el):

The file is attached to this message.

I can reproduce this bug with current CVS:

#0  abort () at emacs.c:431
#1  0x082050dc in get_property_and_range (pos=0, prop=138093161,
    val=0xafa52360, start=0xafa5235c, end=0xafa52358, object=137922809)
    at intervals.c:2321
#2  0x0820c12e in find_composition (pos=0, limit=-1, start=0xafa5235c,
    end=0xafa52358, prop=0xafa52360, object=137922809) at composite.c:415
#3  0x080b7591 in lisp_string_width (string=137922809, precision=-1,
    nchars=0x0, nbytes=0x0) at charset.c:1365
#4  0x081a877e in Fformat (nargs=3, args=0xafa52644) at editfns.c:3590
#5  0x081b17cd in Ffuncall (nargs=4, args=0xafa52640) at eval.c:2978
#6  0x081b109d in Fapply (nargs=3, args=0xafa52744) at eval.c:2485
#7  0x081b17cd in Ffuncall (nargs=4, args=0xafa52740) at eval.c:2978
#8  0x081e92a2 in Fbyte_code (bytestr=140714411, vector=140181220, maxdepth=32)
    at bytecode.c:679
#9  0x081b208e in funcall_lambda (fun=140181404, nargs=3,
    arg_vector=0xafa52a44) at eval.c:3184
#10 0x081b1b4e in Ffuncall (nargs=4, args=0xafa52a40) at eval.c:3043
#11 0x081e92a2 in Fbyte_code (bytestr=140326403, vector=140171500, maxdepth=40)
    at bytecode.c:679
#12 0x081b208e in funcall_lambda (fun=140287860, nargs=0,
    arg_vector=0xafa52d54) at eval.c:3184
#13 0x081b1b4e in Ffuncall (nargs=1, args=0xafa52d50) at eval.c:3043
#14 0x081e92a2 in Fbyte_code (bytestr=140336819, vector=139954612, maxdepth=72)
    at bytecode.c:679
#15 0x081b208e in funcall_lambda (fun=140351404, nargs=4,
    arg_vector=0xafa53074) at eval.c:3184
#16 0x081b1b4e in Ffuncall (nargs=5, args=0xafa53070) at eval.c:3043
#17 0x081e92a2 in Fbyte_code (bytestr=140336851, vector=140228124, maxdepth=40)
    at bytecode.c:679
#18 0x081b208e in funcall_lambda (fun=140200420, nargs=1,
    arg_vector=0xafa533d4) at eval.c:3184
#19 0x081b1b4e in Ffuncall (nargs=2, args=0xafa533d0) at eval.c:3043
#20 0x081ad401 in Fcall_interactively (function=138002969,
    record_flag=137922761, keys=137963276) at callint.c:860
#21 0x0813aeae in Fcommand_execute (cmd=138002969, record_flag=137922761,
    keys=137922761, special=137922761) at keyboard.c:10014
#22 0x0812cde4 in command_loop_1 () at keyboard.c:1873
#23 0x081af4e6 in internal_condition_case (bfun=0x812b9f2 <command_loop_1>,
    handlers=137967417, hfun=0x812b3a2 <cmd_error>) at eval.c:1481
#24 0x0812b74d in command_loop_2 () at keyboard.c:1329
#25 0x081aefa1 in internal_catch (tag=137961401,
    func=0x812b72a <command_loop_2>, arg=137922761) at eval.c:1222
#26 0x0812b703 in command_loop () at keyboard.c:1308
#27 0x0812b120 in recursive_edit_1 () at keyboard.c:1006
#28 0x0812b262 in Frecursive_edit () at keyboard.c:1067
#29 0x08129b18 in main (argc=3, argv=0xafa53ec4) at emacs.c:1761

Lisp Backtrace:
"format" (0x863b973)
"apply" (0x83a5039)
"dired-log" (0x85d35b3)
"dired-byte-compile" (0x83888c9)
"dired-map-over-marks-check" (0x8616619)
"dired-do-byte-compile" (0x83888c9)
"call-interactively" (0x839c219)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

[-- Attachment #2: Fontifier.el --]
[-- Type: application/emacs-lisp, Size: 9077 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs aborts during byte-compilation from Dired

[Kenichi Handa]

In article <877iuablng.fsf@pacem.orebokech.com>, Romain Francoise <romain@orebokech.com> writes:

> I received this report from a Debian user:

> | The latest emacs-snapshot aborts if I try to compile Fontifier.el
> | from the mozart package.
> |
> | I am compiling it from dired (typing B on the line with Fontifier.el):

> The file is attached to this message.

> I can reproduce this bug with current CVS:

> #0  abort () at emacs.c:431
> #1  0x082050dc in get_property_and_range (pos=0, prop=138093161,
>     val=0xafa52360, start=0xafa5235c, end=0xafa52358, object=137922809)
>     at intervals.c:2321

I've just tried with the latest CVS HEAD code and met this
strange error.

At first, I tried to byte-compile Fontifier.el by:

  M-x byte-compile-file RET ~/Fontifier.el RET

then, Emacs signals this error:

  Symbol's value as variable is void: t

Next, I run Emacs under gdb (by M-x gdb), typed C-c C-z to
interrupt it, and then:
(gdb) p Qt
$1 = 137939193
(gdb) xsymbol
$2 = (struct Lisp_Symbol *) 0x838c8f8
"t"
(gdb) p *$2
$3 = {
  gcmarkbit = 0, 
  indirect_variable = 0, 
  constant = 1, 
  interned = 2, 
  xname = 136507507, 
  value = 137939193, 
  function = 137939169, 
  plist = 138484157, 
  next = 0x0
}
(gdb) watch ((struct Lisp_Symbol *) 0x838c8f8)->value
Hardware watchpoint 4: ((struct Lisp_Symbol *) 137939192)->value
(gdb) c
Continuing.

then, did this in Emacs:

  M-x byte-compile-file RET ~/Fontifier.el RET

then, Emacs stopped as below:

Hardware watchpoint 4: ((struct Lisp_Symbol *) 137939192)->value

Old value = 137939193
New value = 144315101
print_preprocess (obj=144315101) at print.c:1415
(gdb) 

The lines around print.c:1415 are:

  1412		  /* If Vprint_continuous_numbering is non-nil and OBJ is a gensym,
  1413		     always print the gensym with a number.  This is a special for
  1414		     the lisp function byte-compile-output-docform.  */
  1415		  if (!NILP (Vprint_continuous_numbering)
  1416		      && SYMBOLP (obj)
  1417		      && !SYMBOL_INTERNED_P (obj))
  1418		    PRINT_NUMBER_STATUS (Vprint_number_table, print_number_index) = Qt;
  1419		  print_number_index++;

I have no idea why the value of Qt is changed at L1415 (note
that I compiled print.c without optimization).

At last, after restaring Emacs, I deleted the local variable
section at the tail of ~/Fontifier.el and byte-compiled it
again.  The compilation finished with these warnings.

Compiling file /home/handa/temp.el at Thu Feb 22 20:31:23 2007

In ozdoc-install-simple:
temp.el:160:30:Warning: reference to free variable `src-buffer'

In ozdoc-process-request:
temp.el:266:18:Warning: reference to free variable `tmp-buffer'
temp.el:281:18:Warning: reference to free variable `out-buffer'

---
Kenichi Handa
handa@m17n.org

Re: Emacs aborts during byte-compilation from Dired

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <877iuablng.fsf@pacem.orebokech.com>, Romain Francoise <romain@orebokech.com> writes:
>
> (gdb) watch ((struct Lisp_Symbol *) 0x838c8f8)->value
> Hardware watchpoint 4: ((struct Lisp_Symbol *) 137939192)->value
> (gdb) c
> Continuing.
>
> then, did this in Emacs:
>
>   M-x byte-compile-file RET ~/Fontifier.el RET
>
> then, Emacs stopped as below:
>
> Hardware watchpoint 4: ((struct Lisp_Symbol *) 137939192)->value
>
> Old value = 137939193
> New value = 144315101
> print_preprocess (obj=144315101) at print.c:1415
> (gdb) 
>
> The lines around print.c:1415 are:
>
>   1412		  /* If Vprint_continuous_numbering is non-nil and OBJ is a gensym,
>   1413		     always print the gensym with a number.  This is a special for
>   1414		     the lisp function byte-compile-output-docform.  */
>   1415		  if (!NILP (Vprint_continuous_numbering)
>   1416		      && SYMBOLP (obj)
>   1417		      && !SYMBOL_INTERNED_P (obj))
>   1418		    PRINT_NUMBER_STATUS (Vprint_number_table, print_number_index) = Qt;
>   1419		  print_number_index++;
>
> I have no idea why the value of Qt is changed at L1415 (note
> that I compiled print.c without optimization).

Well, you'll get pointed to the IP after the hardware breakpoint
triggered.  So the interesting code would be before those comments.

-- 
David Kastrup

Re: Emacs aborts during byte-compilation from Dired

[Kenichi Handa]

In article <E1HKCN4-0005gq-Vi@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

>   1412		  /* If Vprint_continuous_numbering is non-nil and OBJ is a gensym,
>   1413		     always print the gensym with a number.  This is a special for
>   1414		     the lisp function byte-compile-output-docform.  */
>   1415		  if (!NILP (Vprint_continuous_numbering)
>   1416		      && SYMBOLP (obj)
>   1417		      && !SYMBOL_INTERNED_P (obj))
>   1418		    PRINT_NUMBER_STATUS (Vprint_number_table, print_number_index) = Qt;
>   1419		  print_number_index++;

> I have no idea why the value of Qt is changed at L1415 (note
> that I compiled print.c without optimization).

Actually, Qt was changed at this line:

1411		  PRINT_NUMBER_OBJECT (Vprint_number_table, print_number_index) = obj;

And at that time, Vprint_number_table was Qnil but the macro
PRINT_NUMBER_OBJECT assumes that it is a vector.  Someone
who knows the code around here please fix this bug.

---
Kenichi Handa
handa@m17n.org

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> In article <E1HKCN4-0005gq-Vi@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>
>>   1412		  /* If Vprint_continuous_numbering is non-nil and OBJ is a gensym,
>>   1413		     always print the gensym with a number.  This is a special for
>>   1414		     the lisp function byte-compile-output-docform.  */
>>   1415		  if (!NILP (Vprint_continuous_numbering)
>>   1416		      && SYMBOLP (obj)
>>   1417		      && !SYMBOL_INTERNED_P (obj))
>>   1418		    PRINT_NUMBER_STATUS (Vprint_number_table, print_number_index) = Qt;
>>   1419		  print_number_index++;
>
>> I have no idea why the value of Qt is changed at L1415 (note
>> that I compiled print.c without optimization).
>
> Actually, Qt was changed at this line:
>
> 1411		  PRINT_NUMBER_OBJECT (Vprint_number_table, print_number_index) = obj;
>
> And at that time, Vprint_number_table was Qnil but the macro
> PRINT_NUMBER_OBJECT assumes that it is a vector.  Someone
> who knows the code around here please fix this bug.
>
> ---
> Kenichi Handa
> handa@m17n.org

Removing this line seems to cure the problem:

;;; byte-compile-compatibility: t ***


I don't know how it is related, but it does narrow down the
possible causes of the crash / anomaly.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

If you M-x byte-compile-file this reduced version,
Emacs will loop while byte-compiling the defun.

;;;--------------------------
(defconst ozdoc-mark-begin "\004B")

(defun ozdoc-next-mark ()
  "leaves point in front of next <MARK ...>"
  (skip-chars-forward "^\004"))

(defun ozdoc-parse-spec ()
  t)

\f
;;; Local Variables: ***
;;; mode: emacs-lisp ***
;;; byte-compile-dynamic-docstrings: nil ***
;;; byte-compile-compatibility: t ***
;;; End: ***
;;;--------------------------

Again, Qt looks bogus:

(gdb) p Qt
$5 = 137819681
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$6 = (struct Lisp_Symbol *) 0x836f620
0
(gdb) 


Removing this line seems to cure the problem:

;;; byte-compile-compatibility: t ***


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs aborts during byte-compilation from Dired

[Romain Francoise]

storm@cua.dk (Kim F. Storm) writes:

> Removing this line seems to cure the problem:

> ;;; byte-compile-compatibility: t ***

Do people still use Emacs 18?

Perhaps we should simply get rid of this option and the associated
code.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

Romain Francoise <romain@orebokech.com> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> Removing this line seems to cure the problem:
>
>> ;;; byte-compile-compatibility: t ***
>
> Do people still use Emacs 18?
>
> Perhaps we should simply get rid of this option and the associated
> code.

Maybe, but we still need to figure out why it causes havoc,
as it may surface in other cases too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

Here's another file which will also destroy `t' on the way.

If you change defconst to defvar the bug goes away!!

(defconst ozdoc-mark-begin "XB")
(defconst ozdoc-mark-end   "XE")
(defconst ozdoc-mark-text  "XT")
(defconst ozdoc-mark-open  "XO")
(defconst ozdoc-mark-close "XC")

(defun ozdoc-next-mark ()
  "leaves point in front of next MARK"
  (skip-chars-forward "X"))

(defun ozdoc-parse-spec ()
  t)

\f
;;; Local Variables: ***
;;; mode: emacs-lisp ***
;;; byte-compile-dynamic-docstrings: nil ***
;;; byte-compile-compatibility: t ***
;;; End: ***


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

>>
>> Actually, Qt was changed at this line:
>>
>> 1411		  PRINT_NUMBER_OBJECT (Vprint_number_table, print_number_index) = obj;
>>
>> And at that time, Vprint_number_table was Qnil but the macro
>> PRINT_NUMBER_OBJECT assumes that it is a vector.  Someone
>> who knows the code around here please fix this bug.

It turns out that byte-compile-output-docform sets 
print-continuous-numbering to t and print-number-table to nil.

This means that Vprint_number_table is NIL but print_number_index > 0,
so the Vprint_number_table vector is not allocated.

I have installed a fix (resetting print_number_index if
Vprint_number_table is nil even if print-continuous-numbering is
non-nil.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs aborts during byte-compilation from Dired

[Richard Stallman]

    > ;;; byte-compile-compatibility: t ***

    Do people still use Emacs 18?

We can delete that, but we should still fix the bug.

Re: Emacs aborts during byte-compilation from Dired

[Romain Francoise]

storm@cua.dk (Kim F. Storm) writes:

> I have installed a fix (resetting print_number_index if
> Vprint_number_table is nil even if print-continuous-numbering is
> non-nil).

Thanks!

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Emacs aborts during byte-compilation from Dired

[Richard Stallman]

    I have installed a fix (resetting print_number_index if
    Vprint_number_table is nil even if print-continuous-numbering is
    non-nil.

Thanks for fixing this.

Re: Emacs aborts during byte-compilation from Dired

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > ;;; byte-compile-compatibility: t ***
>
>     Do people still use Emacs 18?
>
> We can delete that, 
>
.. after the release!!!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk