[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs crashes
>>>>> In [emacs-w3m : No.08128] Kim F. Storm wrote:
> What does "xbacktrace" in gdb show?
(gdb) xbacktrace
"string-width"
"w3m-modeline-title"
The w3m-modeline-title function (which uses string-width) is
used as one of the mode-line-format elements like the following:
(:eval (w3m-modeline-title))
It returns the title string of the web page which is truncated
so as to be fit to the window width dynamically.
> Pls. also try the commands below:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0809704f in lisp_string_width (string=149514347, precision=-1, nchars=0x0,
>> nbytes=0x0) at charset.c:1377
>> 1377 PARSE_MULTIBYTE_SEQ (str + i_byte, len_byte - i_byte, bytes);
>> (gdb) bt
>> #0 0x0809704f in lisp_string_width (string=149514347, precision=-1,
>> nchars=0x0, nbytes=0x0) at charset.c:1377
> pp string
The data returned are too big to send. What is what I should
pay attention?
>> #1 0x08097116 in Fstring_width (string=153333780) at charset.c:1415
> up
#1 0x08097116 in Fstring_width (string=153323540) at charset.c:1415
1415 XSETFASTINT (val, lisp_string_width (string, -1, NULL, NULL));
> pp string
[138568309 (
Program received signal SIGSEGV, Segmentation fault.
0x0815fcbe in print_object (obj=706748453, printcharfun=137486193,
escapeflag=1) at print.c:1784
1784 print_object (XCAR (obj), printcharfun, escapeflag);
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (debug_print) will be abandoned.
>> #2 0x0814cfaf in Ffuncall (nargs=2, args=0x6f3b97) at eval.c:2790
>> #3 0x081763c0 in Fbyte_code (bytestr=146859528, vector=1,
>> maxdepth=-1073752640) at bytecode.c:686
>> #4 0x0814d3a3 in funcall_lambda (fun=146877780, nargs=0,
>> arg_vector=0xbfffd67c) at eval.c:2979
>> #5 0x0814d228 in apply_lambda (fun=0, args=1, eval_flag=1) at eval.c:2901
>> #6 0x0814c275 in Feval (form=1) at eval.c:2191
>> #7 0x0814b354 in internal_condition_case_1 (bfun=0x814c0c0 <Feval>,
>> arg=146202181, handlers=137397969, hfun=0x8062910 <safe_eval_handler>)
>> at eval.c:1430
>> #8 0x080629aa in safe_eval (sexpr=0) at xdisp.c:1979
>> #9 0x08078a45 in display_mode_element (it=0xbfffda80, depth=5,
>> field_width=-13, precision=-24, elt=0, props=137397921, risky=0)
>> at xdisp.c:16052
> up 8
#8 0x081763c0 in Fbyte_code (bytestr=146900216, vector=1,
maxdepth=-1073755488) at bytecode.c:686
686 TOP = Ffuncall (op + 1, &TOP);
> p elt
No symbol "elt" in current context.
> (is elt really 0 here? If not, try:
> pp elt
> )
No symbol "elt" in current context.
>> #10 0x0807891c in display_mode_element (it=0xbfffda80, depth=3, field_width=0,
>> precision=-11, elt=145091869, props=137397921, risky=0) at xdisp.c:16133
> up
#9 0x0814d3a3 in funcall_lambda (fun=146918468, nargs=0,
arg_vector=0xbfffcb5c) at eval.c:2979
2979 val = Fbyte_code (AREF (fun, COMPILED_BYTECODE),
> pp elt
No symbol "elt" in current context.
[...]
Regards,