From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: display word wrapping Date: Sun, 30 May 2004 18:50:27 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040530175117.C69B.LEKTU@mi.madritel.es> References: <20040530002547.6961.LEKTU@mi.madritel.es> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1085935854 5906 80.91.224.253 (30 May 2004 16:50:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 30 May 2004 16:50:54 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 30 18:50:45 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUTWH-0003Xc-00 for ; Sun, 30 May 2004 18:50:45 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUTWH-0007VY-00 for ; Sun, 30 May 2004 18:50:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUTWQ-0004bJ-0v for emacs-devel@quimby.gnus.org; Sun, 30 May 2004 12:50:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BUTWM-0004Zl-3D for emacs-devel@gnu.org; Sun, 30 May 2004 12:50:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BUTWK-0004Z4-NV for emacs-devel@gnu.org; Sun, 30 May 2004 12:50:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUTWK-0004Yv-EI for emacs-devel@gnu.org; Sun, 30 May 2004 12:50:48 -0400 Original-Received: from [62.81.186.19] (helo=smtp09.retemail.es) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BUTW0-00019Y-MD for emacs-devel@gnu.org; Sun, 30 May 2004 12:50:29 -0400 Original-Received: from [127.0.0.1] ([213.37.34.123]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040530165026.ZEVZ1181.smtp09.retemail.es@[127.0.0.1]> for ; Sun, 30 May 2004 18:50:26 +0200 Original-To: emacs-devel@gnu.org In-Reply-To: X-Mailer: Becky! ver. 2.09.01 [en] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24225 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24225 On 30 May 2004 08:12:41 +0200, Eli Zaretskii wrote: > Does it crash (it _is_ a crash, isn't it?) under a debugger, or does > that, too, cause the bug to change its behavior? Yes, it is a crash. No, it fails the same way under debugging. > If the former, run an unmodified optimized code under a debugger and > use debugger facilities instead of debugging code to see what's wrong. Yeah, I've already tried, and I see *where* it is failing, but debugging optimized code is a bit of a pain. > Comparison of machine code in the optimized and unoptimized versions > might also tell you something useful. It would, if I were more sure about what the code is exactly supposed to do. I'm no expert in the image code. > Finally, assuming that we are talking about a crash, posting the > detailed description of the crash (exception number, register dump, > stack dump, etc.) here could give some further ideas. When I try to load a 811-byte .gif, I get: Unhandled exception at 0x0106dd08 in emacs.exe: 0xC0000005: Access violation reading location 0x00000004. The stack trace is: image_spec_value(int spec=-536870912, int key=557610632, int * found=0x00000000) Line 931 + 0x8 C lookup_image(frame * f=0x015dbe00, int spec=-1572937664) Line 1682 C handle_single_display_prop(it * it=0x00000000, int prop=5, int object=-2109577216, text_pos * position=0x0082f04c, int display_replaced_before_p=0) Line 3702 C handle_display_prop(it * it=0x0082f04c) Line 3339 + 0x10 C handle_stop(it * it=0x0082efb0) Line 2591 + 0x3 C reseat(it * it=0x00000000, text_pos pos={...}, int force_p=1) Line 4676 + 0x6 C init_iterator(it * it=0x0082efb0, window * w=0x015dbe00, int charpos=1, int bytepos=1, glyph_row * row=0x02426800, face_id base_face_id=DEFAULT_FACE_ID) Line 2269 + 0x18 C start_display(it * it=0x0082efb0, window * w=0x0211ac00, text_pos pos={...}) Line 2288 + 0x1f C try_window(int window=-2112771072, text_pos pos={...}) Line 12211 + 0x20 C redisplay_window(int window=-2112771072, int just_this_one_p=0) Line 11858 + 0xc C redisplay_window_0(int window=-2112771072) Line 10588 + 0xa C internal_condition_case_1(int (void)* bfun=0x0103fbcb, int arg=-2112771072, int handlers=-1589824248, int (void)* hfun=0x01029d11) Line 1374 + 0x35 C redisplay_windows(int window=-2112771072) Line 10569 + 0x1d C redisplay_internal(int preserve_echo_area=0) Line 10152 + 0x8 C redisplay() Line 9386 + 0x7 C read_char(int commandflag=1, int nmaps=5, int * maps=0x0082fbec, int prev_event=557609984, int * used_mouse_menu=0x0082fc44) Line 2487 C read_key_sequence(int * keybuf=0x0082fce8, int bufsize=30, int prompt=557609984, int dont_downcase_last=0, int can_return_switch_frame=1, int fix_current_buffer=1) Line 8783 + 0x24 C command_loop_1() Line 1490 + 0x25 C internal_condition_case(int (void)* bfun=0x0105b380, int handlers=557688384, int (void)* hfun=0x01058003) Line 1334 C command_loop_2() Line 1271 + 0x15 C internal_catch(int tag=557684672, int (void)* func=0x0105c094, int arg=557609984) Line 1094 + 0x6 C command_loop() Line 1251 C recursive_edit_1() Line 961 + 0x5 C Frecursive_edit() Line 1023 C main() Line 1693 + 0x5 C mainCRTStartup() Line 259 + 0x12 C GetCurrentDirectoryW() + 0x44 lookup_image is calling image_spec_value with the following code: if (! img->background_valid) { bg = image_spec_value (img->spec, QCbackground, NULL); if (!NILP (bg)) { img->background = x_alloc_image_color (f, img, bg, FRAME_BACKGROUND_PIXEL (f)); img->background_valid = 1; } } At that point, img->spec is not valid. Previously, img has been initialized from spec (the arg passed to the function), so spec and img->spec should be equal, but they aren't anymore. If you change the call to do bg = image_spec_value (spec, QCbackground, NULL); it succeeds, but then the call to postprocess_image if (!EQ (*img->type->type, Qpostscript)) postprocess_image (f, img); fails for the same reason (img->spec is not valid). On optimized code, img is not on the stack, but on a register. In fact, if I change struct image *img; to static struct image *img; Emacs works fine. So it looks like it *is* really a bug in the optimizer code, which is clobbering a register or something like that. /L/e/k/t/u