Re: Lockup
YAMAMOTO Mitsuharu skrev: On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv <[EMAIL PROTECTED]> said: My intention was that the above scenario would be avoided with BLOCK_INPUT around functions that may call malloc-related functions. It does not help if the calling thread is one of the Gnoem threads. But a signal delivered to a non-main thread is redirected to the main thread by SIGNAL_THREAD_CHECK. A signal yes, but I was thinking of this scenario: A Gnome thread does malloc, gets the mutex lock and enters the malloc code. A signal is delivered (in the main thread as you point out) and enters malloc also. This situation is exactly like the one with the lockup, but here we can't use BLOCK_INPUT around the malloc related functions because they are in the Gnome code. How about just changing the order of lock/unlock and BLOCK_INPUT/UNBLOCK_INPUT in the previous version of BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC? That would mean that lock/unlock mutex functions are called in the signal handler context, which is not allowed according to the documentation. Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I think it's better than the current one, i.e., not protecting shared resources such as __malloc_hook in the signal handler context. I agree with your assumtion that the lockuo occurs because the signal handler and the interrupted therad are calling pthread_mutex_(un)lock for the same mutex. But BLOCK_INPUT does not help, because Gnome code does not have it. So I tried to do the next best thing, i.e. block SIGIO in non-main threads. The problem with this is that I can't block SIGIO before taking the mutex, because if I hang when taking the mutex, SIGIO would remain blocked. One could use trylock and some sort of busy loop, but I don't think that is usable. (Of course SYNC_INPUT is the right direction, but the current plan is not enabling it in the next release as far as I understand.) Unless someone comes up with a supersafe scheme I think we have to live with this race condition until then. But it is better now than before, SIGIO and the main thread executing the sam (un)lock should not lockup. But if the signal handler is executing in one thread one one processor and a Gnome thread is executing on another processor, there could be a lockup. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during ask-user-about-lock
Richard Stallman skrev: I was afraid your question was going to be "WHY does Emacs get a drag'n'drop event?", because I don't know the answer (and it doesn't make much sense to me). It is an interesting question, because if you didn't try to do a drag'n'drop, the event could reflect a bug. But you COULD have done a real drag'n'drop, and generated a legitimate drag-and-drop event. So the question of how to handle one still exists. I will install my patch if no one objects in the next few days. I think the problem is elsewhere. The dnd code has a flaw in it, it generates dnd-events (lisp events) for wrong ClientMessages (X events), in this case a _MOTIF_WM_MESSAGES ClientMessage. These non-real dnd events gets filtered out in x-dnd-handle-drag-n-drop-event (x-dnd.el) so they have no impact normally. I didn't realize they could interfere in other ways. I'll rework the generation of dnd lisp events so they are generated for genuine X dnd events only. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
> On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv <[EMAIL PROTECTED]> said: >> My intention was that the above scenario would be avoided with >> BLOCK_INPUT around functions that may call malloc-related >> functions. > It does not help if the calling thread is one of the Gnoem threads. But a signal delivered to a non-main thread is redirected to the main thread by SIGNAL_THREAD_CHECK. >> How about just changing the order of lock/unlock and >> BLOCK_INPUT/UNBLOCK_INPUT in the previous version of >> BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC? > That would mean that lock/unlock mutex functions are called in the > signal handler context, which is not allowed according to the > documentation. Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I think it's better than the current one, i.e., not protecting shared resources such as __malloc_hook in the signal handler context. (Of course SYNC_INPUT is the right direction, but the current plan is not enabling it in the next release as far as I understand.) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
visiting "~/Application Data" gets "~" instead
In GNU Emacs 22.0.50.1 (i386-mingw-nt5.0.2195) of 2006-07-27 on SLOP X server distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.2)' * Start emacs with "runemacs -Q" * paste or type this into the *scratch* buffer, and hit C-x C-e (progn (setenv "HOME" (getenv "USERPROFILE")) ;;(setq abbreviated-home-dir nil) (let ((home (find-file-noselect "~/")) (ad (find-file-noselect "~/Application Data/"))) (when (eq home ad) (error "Aha. We found the bug.")) (message "I guess the bug is fixed or hidden."))) I predict you'll see the error "Aha. We found the bug." I think this is a bug because I've changed the HOME variable to be "c:/Documents and Settings/erich/", and yet appending "Application Data" to that name, and visiting the result, gets the same buffer as if I hadn't appended "Application Data". For reasons I don't really understand, if you uncomment the line that sets abbreviated-home-dir, the problem goes away. Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-f c : / b u C-M-n C-x C-e q C-x C-e q C-p C-p C-p C-p M-m C-d C-d M-> C-x C-e C-p C-p C-M-n M-( m e s s a g e SPC " " C-b I SPC g u e s s SPC t h e SPC b u g SPC i s SPC f i x e d SPC o r SPC h i d d e n . C-e C-x C-e C-x C-s M-x r e p o r t - e m a c s - b u Recent messages: Loading help-mode...done Back to top level. Entering debugger... Back to top level. Mark set nil I guess the bug is fixed or hidden. "I guess the bug is fixed or hidden." Wrote c:/bug.el Loading emacsbug...done -- ... democracy is the worst form of government except all those other forms that have been tried from time to time. -- Winston Churchill, cited at http://en.wikipedia.org/wiki/Democracy ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Multiple runs of menu-bar-update-hook
You can see that both calls have come via redisplay(); the difference is their callers. (Of course both runs of the hook are unnecessary, they have been carried out because windows_or_buffers_changed = 1.) In the first: Normally, windows_or_buffers_changed gets cleared near the end of redisplay_internal. Did the first call to redisplay_internal do that? If not, why not? If it did that, where did it get set again before the second call to redisplay? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Busy wait in Emacs
Please follow the advice in etc/DEBUG specifically for debugging situations like this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error during ask-user-about-lock
I was afraid your question was going to be "WHY does Emacs get a drag'n'drop event?", because I don't know the answer (and it doesn't make much sense to me). It is an interesting question, because if you didn't try to do a drag'n'drop, the event could reflect a bug. But you COULD have done a real drag'n'drop, and generated a legitimate drag-and-drop event. So the question of how to handle one still exists. I will install my patch if no one objects in the next few days. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible cygwin memory problems
> From: "emacs user" <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > Bcc: > Date: Thu, 10 Aug 2006 01:06:22 -0400 > > #kill it > #(clear-image-cache t) > I am here1 > I am here2 > I am here4 > I am here5 > I am here6 > I am here5 > I am here6 Okay, thanks. This shows that free_image does get called. What image types did you try till now? If you tried with only one image type, please see if other image types exhibit the same problem (i.e. that memory is not returned to system when an image is killed and the image cache cleared). If you already tried all the supported image types, I cannot think of any reason but one: that the Cygwin implementation of malloc/free does not return freed memory to the OS. If this is the conclusion, then it should probably be taken up with Cygwin maintainers on their mailing list. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Busy wait in Emacs
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: At some point of time, an Emacs GTK+ X11 session left alone suddenly decided to devour full CPU power, with the cursor only blinking infrequently. This is a build from yesterday. Hardly surprising, sit-for is involved. If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. See here: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb774808d in select () from /lib/tls/i686/cmov/libc.so.6 #2 0x08182933 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfa00198, xfd=0x0, tmo=0x0) at /home/tmp/emacs/src/process.c:4189 #3 0x08184812 in wait_reading_process_output (time_limit=0, microsecs=499903, read_kbd=-1, do_display=1, wait_for_cell=137427145, wait_proc=0x0, just_wait_proc=0) at /home/tmp/emacs/src/process.c:4558 #4 0x080fa298 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=137427193, used_mouse_menu=0x0, end_time=0xbfa00548) at /home/tmp/emacs/src/keyboard.c:3962 #5 0x08166a7f in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_method=0, seconds=137417878) at /home/tmp/emacs/src/lread.c:495 #6 0x08166d56 in Fread_event (prompt=137427145, inherit_input_method=137427145, seconds=-514) at /home/tmp/emacs/src/lread.c:600 #7 0x081531df in Ffuncall (nargs=4, args=0xbfa00600) at /home/tmp/emacs/src/eval.c:2988 #8 0x0817ca2e in Fbyte_code (bytestr=136060667, vector=136060684, maxdepth=40) at /home/tmp/emacs/src/bytecode.c:679 #9 0x08152bea in funcall_lambda (fun=136060604, nargs=1, arg_vector=0xbfa00734) at /home/tmp/emacs/src/eval.c:3169 #10 0x08153040 in Ffuncall (nargs=2, args=0xbfa00730) at /home/tmp/emacs/src/eval.c:3028 #11 0x0817ca2e in Fbyte_code (bytestr=136485603, vector=136485628, maxdepth=48) at /home/tmp/emacs/src/bytecode.c:679 #12 0x08152768 in Feval (form=136485589) at /home/tmp/emacs/src/eval.c:2319 #13 0x08154a21 in internal_lisp_condition_case (var=137427145, bodyform=136485589, handlers=136485941) at /home/tmp/emacs/src/eval.c:1414 #14 0x0817dbe0 in Fbyte_code (bytestr=136485515, vector=136485532, maxdepth=32) at /home/tmp/emacs/src/bytecode.c:869 #15 0x08152bea in funcall_lambda (fun=136485484, nargs=0, arg_vector=0xbfa00b08) at /home/tmp/emacs/src/eval.c:3169 #16 0x08153040 in Ffuncall (nargs=1, args=0xbfa00b04) at /home/tmp/emacs/src/eval.c:3028 #17 0x0815461f in Fapply (nargs=2, args=0xbfa00b04) at /home/tmp/emacs/src/eval.c:2411 #18 0x0815331e in Ffuncall (nargs=3, args=0xbfa00b00) at /home/tmp/emacs/src/eval.c:2963 #19 0x0817ca2e in Fbyte_code (bytestr=136511459, vector=136511484, maxdepth=32) at /home/tmp/emacs/src/bytecode.c:679 #20 0x08152768 in Feval (form=136511445) at /home/tmp/emacs/src/eval.c:2319 #21 0x08154a21 in internal_lisp_condition_case (var=137427145, bodyform=136511445, handlers=136511517) at /home/tmp/emacs/src/eval.c:1414 #22 0x0817dbe0 in Fbyte_code (bytestr=136511315, vector=136511332, maxdepth=40) at /home/tmp/emacs/src/bytecode.c:869 #23 0x08152bea in funcall_lambda (fun=136511276, nargs=1, arg_vector=0xbfa00e44) at /home/tmp/emacs/src/eval.c:3169 #24 0x08153040 in Ffuncall (nargs=2, args=0xbfa00e40) at /home/tmp/emacs/src/eval.c:3028 #25 0x08154257 in call1 (fn=137462553, arg1=145505828) at /home/tmp/emacs/src/eval.c:2767 #26 0x080f2368 in timer_check (do_it_now=1) at /home/tmp/emacs/src/keyboard.c:4507 #27 0x080f24eb in readable_events (flags=1) at /home/tmp/emacs/src/keyboard.c:3532 #28 0x080f9669 in get_input_pending (addr=0x82fd5b8, flags=1) at /home/tmp/emacs/src/keyboard.c:6626 #29 0x080f9721 in detect_input_pending_run_timers (do_display=1) at /home/tmp/emacs/src/keyboard.c:1 #30 0x081848c4 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137427145, wait_proc=0x0, just_wait_proc=0) at /home/tmp/emacs/src/process.c:4661 #31 0x0805ac2b in sit_for (timeout=240, reading=1, do_display=1) at /home/tmp/emacs/src/dispnew.c:6543 #32 0x080faa79 in read_char (commandflag=1, nmaps=4, maps=0xbfa014d0, prev_event=137427145, used_mouse_menu=0xbfa01578, end_time=0x0) at /home/tmp/emacs/src/keyboard.c:2783 #33 0x080fc4cf in read_key_sequence (keybuf=0xbfa01614, bufsize=30, prompt=137427145, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /home/tmp/emacs/src/keyboard.c:8902 #34 0x080fdf9d in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1535 #35 0x0815167c in internal_condition_case (bfun=0x80fde09 , handlers=137471809, hfun=0x80f6520 ) at /home/tmp/emacs/src/eval.c:1469 #36 0x080f0b5f in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1326 #37 0x08151380 in internal_catch (tag=-514, func=0x80f0b3c , arg=137427145) at /home/tmp/emacs/src/eval.c:1210 #38 0x080f0991 in command_loop () at /home/tmp
Re: On Cygwin: bootstrap hangs when compiling lisp files...
> Date: Thu, 10 Aug 2006 09:30:06 -0400 > From: "Ping Liang" <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > [Switching to thread 3340.0xe18] > (gdb) bt > #0 0x7c901231 in ntdll!DbgUiConnectToDbg () >from /cygdrive/c/WINDOWS/system32/ntdll.dll > #1 0x7c9507a8 in ntdll!KiIntSystemCall () >from /cygdrive/c/WINDOWS/system32/ntdll.dll > #2 0x0005 in ?? () > #3 0x0004 in ?? () > #4 0x0001 in ?? () > #5 0x1873ffd0 in ?? () > #6 0x0246 in ?? () > #7 0x in ?? () > #8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll > #9 0x7c9507c8 in ntdll!KiIntSystemCall () >from /cygdrive/c/WINDOWS/system32/ntdll.dll > #10 0x in ?? () > (gdb) Thanks. This shows that Emacs was in a system call when you stopped it. You should now use the technique described in etc/DEBUG to find out where it is looping. Search for the section in DEBUG named "If the symptom of the bug is that Emacs fails to respond", and use the `finish' command as described there to find out where in the Emacs sources it loops. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Typos in mule.texi
Sven Joachim <[EMAIL PROTECTED]> writes: > two typos in > man/mule.texi. The following patch gets rid of them: thanks, installed. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: `facemenu-set-face' doesn't add face to the Face menu
I clarified the doc string of facemenu-listed-faces. Thx ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `facemenu-set-face' doesn't add face to the Face menu
I clarified the doc string of facemenu-listed-faces. Thanks for pointing out what was confusing. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `facemenu-set-face' doesn't add face to the Face menu
No, I wasn't thinking about merging. Perhaps it would help to have the manual's description of `facemenu-set-face' cross-reference the section that explains that text can have a list of faces, and how that works. It's not needed for the doc string, of course. I cleaned up the text in text.texi, and also fixed a bug in the code. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: reproducible cygwin memory problems
first, I noticed that when I undef rel_alloc, while this seems to add some stability while editing images, there seems to be a problem with returning memory to the OS even with text files. That does not surprise me. Ordinary malloc can't in general return space to the OS. All it can do is reuse the block if it needs another the same size. I wrote rel_alloc as a way to solve this particular problem. On GNU/Linux we don't need it now, because the malloc in GNU libc allocates large blocks by creating separate pages which it can return to the kernel. But on systems that don't do this, rel_alloc is still very important. Turning off rel_alloc may be useful for investigating this problem, but it certainly isn't the solution. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs completion inferior to bash's
C-x C-f s s We need the second tab to see the Sole completion message, This is how it was designed to work. It is not clear to me that changing it would be an improvement. However, if someone implements that change, we could ask the users if they like it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Error during ask-user-about-lock
> The question is, what SHOULD Emacs do when a drag-and-drop > event arrives while it is asking the user a question? I was afraid your question was going to be "WHY does Emacs get a drag'n'drop event?", because I don't know the answer (and it doesn't make much sense to me). > One possibility is, what it does now. > > Another possibility is, handle the drag-and-drop event "on the side" > and continue asking. That could be implemented by binding it on > special-event-map, as shown below. > > Do you like the results of this change? Does anyone think it > is a mistake? Well, it works, and I still seem to be able to drag items from CDE's File Manager into Emacs. (I have never used drag'n'drop before---I use Dired.) I can't comment on it otherwise... Thanks, Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: On Cygwin: bootstrap hangs when compiling lisp files...
I was able to take the latter approach and it worked. Here is the traceback Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dllLoaded symbols for /usr/bin/cygncurses-8.dllLoaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/ws2_32.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/msvcrt.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/ws2help.dllLoaded symbols for /cygdrive/c/WINDOWS/System32/mswsock.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/dnsapi.dllLoaded symbols for /cygdrive/c/WINDOWS/System32/winrnr.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/wldap32.dllLoaded symbols for /cygdrive/c/WINDOWS/system32/rasadhlp.dll[Switching to thread 3340.0xe18](gdb) bt#0 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll#1 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll#2 0x0005 in ?? ()#3 0x0004 in ?? ()#4 0x0001 in ?? () #5 0x1873ffd0 in ?? ()#6 0x0246 in ?? ()#7 0x in ?? ()#8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll#9 0x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? ()(gdb) On 8/9/06, Eli Zaretskii <[EMAIL PROTECTED]> wrote: > Date: Wed, 9 Aug 2006 22:50:44 -0400> From: "Ping Liang" < [EMAIL PROTECTED]>>> Sorry it takes this long to reply. When I ran it under gdb, control-c> wouldn't break it. I ended up getting out by killing the process itself> (took 40% cpu). So I couldn't do bt. >> Any other hint, please?There's no way to debug this except if we can interrupt Emacs whenit's looping. I don't know how to do that, since I don't use Cygwin.Please ask on the Cygwin mailing list how to interrupt a Cygwin program when it runs under GDB; perhaps you can use the `kill'command, if you have its Cygwin port installed.Another possibility is to run Emacs outside GDB, and when it startslooping invoke GDB as "gdb -p PID", where PID is the Emacs process ID number. If that succeeds, it will stop Emacs, and you should then beable to do a backtrace.And please don't remove the mailing list from the CC header, I'd liketo keep this discussion on the list so that others could contribute ideas. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Multiple runs of menu-bar-update-hook
> Was update_menu_bar called twice from a single call to > prepare_menu_bars? > If so, that means the mechanism I recently added to prevent > that is broken. > > Or was prepare_menu_bars called twice? If so, how was it > called, each time? It was called twice. Sorry if this still isn't clear, this is just the stack frames I sent earlier, but from a gcc build. This is the first call: Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902 #3 0x00083ecc in redisplay () at xdisp.c:10491 #4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555 #5 0x00270af4 in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_method=0, seconds=4687873) at lread.c:495 #6 0x00270eb0 in Fread_event (prompt=4687873, inherit_input_method=4687873, seconds=4687873) at lread.c:600 #7 0x0024ab14 in Ffuncall (nargs=1, args=0xffbecec0) at eval.c:2988 #8 0x002a2cb8 in Fbyte_code (bytestr=3725827, vector=3725852, maxdepth=48) at bytecode.c:679 #9 0x002492a4 in Feval (form=3725813) at eval.c:2319 #10 0x00244430 in Fprogn (args=3725805) at eval.c:435 #11 0x00180a68 in Ftrack_mouse (args=3725805) at keyboard.c:3498 #12 0x00248fe8 in Feval (form=3725797) at eval.c:2260 #13 0x00244430 in Fprogn (args=3725789) at eval.c:435 #14 0x0024b554 in funcall_lambda (fun=3725773, nargs=0, arg_vector=0xffbed54c) at eval.c:3162 #15 0x0024ae14 in Ffuncall (nargs=1, args=0xffbed548) at eval.c:3039 #16 0x002a2cb8 in Fbyte_code (bytestr=3725379, vector=3725396, maxdepth=48) at bytecode.c:679 #17 0x0024b5b8 in funcall_lambda (fun=3725324, nargs=2, arg_vector=0xffbed81c) at eval.c:3169 #18 0x0024ad30 in Ffuncall (nargs=3, args=0xffbed818) at eval.c:3028 #19 0x002a2cb8 in Fbyte_code (bytestr=3724235, vector=3724252, maxdepth=40) at bytecode.c:679 #20 0x0024b5b8 in funcall_lambda (fun=3724196, nargs=1, arg_vector=0xffbedb0c) at eval.c:3169 #21 0x0024ad30 in Ffuncall (nargs=2, args=0xffbedb08) at eval.c:3028 #22 0x00243528 in Fcall_interactively (function=7566081, record_flag=4687873, keys=4747268) at callint.c:880 #23 0x00190a7c in Fcommand_execute (cmd=7566081, record_flag=4687873, keys=4687873, special=4687873) at keyboard.c:9797 #24 0x0017b290 in command_loop_1 () at keyboard.c:1790 #25 0x00246eb4 in internal_condition_case (bfun=0x17910c , handlers=4752009, hfun=0x178734 ) at eval.c:1469 #26 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #27 0x00246644 in internal_catch (tag=4746241, func=0x178dac , arg=4687873) at eval.c:1210 #28 0x00178d50 in command_loop () at keyboard.c:1305 #29 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #30 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #31 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794 Lisp Backtrace: "read-event" (0x0) "byte-code" (0x38da03) "track-mouse" (0x38d9ed) 0x38d9cd Lisp type 5 "mouse-drag-track" (0x5c44ed) "mouse-drag-region" (0x5c44ed) "call-interactively" (0x737301) (gdb) The second call is: Breakpoint 5, update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 (gdb) where #0 update_menu_bar (f=0x997400, save_match_data=0, hooks_run=0) at xdisp.c:9195 #1 0x000806ac in prepare_menu_bars () at xdisp.c:9073 #2 0x00085810 in redisplay_internal (preserve_echo_area=0) at xdisp.c:10902 #3 0x00083ecc in redisplay () at xdisp.c:10491 #4 0x0017dba4 in read_char (commandflag=1, nmaps=2, maps=0xffbedb60, prev_event=4687873, used_mouse_menu=0xffbedcb4, end_time=0x0) at keyboard.c:2555 #5 0x0018dd50 in read_key_sequence (keybuf=0xffbede60, bufsize=30, prompt=4687873, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8902 #6 0x00179668 in command_loop_1 () at keyboard.c:1535 #7 0x00246eb4 in internal_condition_case (bfun=0x17910c , handlers=4752009, hfun=0x178734 ) at eval.c:1469 #8 0x00178dd8 in command_loop_2 () at keyboard.c:1326 #9 0x00246644 in internal_catch (tag=4746241, func=0x178dac , arg=4687873) at eval.c:1210 #10 0x00178d50 in command_loop () at keyboard.c:1305 #11 0x00178280 in recursive_edit_1 () at keyboard.c:1003 #12 0x001784e0 in Frecursive_edit () at keyboard.c:1064 #13 0x001760a4 in main (argc=2, argv=0xffbee43c) at emacs.c:1794 (gdb) Which I assume is the main loop. You can see that both calls have come via redisplay(); the difference is their callers. (Of course both runs of the hook are unnecessary, they have been carried out because windows_or_buffers_changed = 1.) In the first: #4 0x0017dba4 in read_char (commandflag=0, nmaps=0, maps=0x0, prev_event=4687921, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2555 #5 0x00270af4 in read_filtered_event (no_switch_frame=0, ascii_required=0, error_nonascii=0, input_meth
Re: Lockup
YAMAMOTO Mitsuharu skrev:
On Thu, 10 Aug 2006 10:11:55 +0200, Jan Djärv <[EMAIL PROTECTED]> said:
In this particular case it would help, but in general the problem is
that the signal handler gets called when the main thread is
executing in the mutex code (pthread_mutex_unlock). Later when the
signal handler tries to get the mutex, it locks up,
My intention was that the above scenario would be avoided with
BLOCK_INPUT around functions that may call malloc-related functions.
It does not help if the calling thread is one of the Gnoem threads.
How about just changing the order of lock/unlock and
BLOCK_INPUT/UNBLOCK_INPUT in the previous version of
BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC?
#define BLOCK_INPUT_ALLOC \
do\
{ \
if (pthread_self () == main_thread) \
BLOCK_INPUT;\
pthread_mutex_lock (&alloc_mutex);\
} \
while (0)
#define UNBLOCK_INPUT_ALLOC \
do\
{ \
pthread_mutex_unlock (&alloc_mutex); \
if (pthread_self () == main_thread) \
UNBLOCK_INPUT; \
} \
while (0)
That would mean that lock/unlock mutex functions are called in the signal
handler context, which is not allowed according to the documentation.
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
> On Thu, 10 Aug 2006 10:11:55 +0200, Jan Djärv <[EMAIL PROTECTED]> said:
>> Maybe I'm missing something, but doesn't adding BLOCK_INPUT around
>> closedir (and opendir) help?
> In this particular case it would help, but in general the problem is
> that the signal handler gets called when the main thread is
> executing in the mutex code (pthread_mutex_unlock). Later when the
> signal handler tries to get the mutex, it locks up,
My intention was that the above scenario would be avoided with
BLOCK_INPUT around functions that may call malloc-related functions.
> it is actually not allowed to call mutex functions from a signal
> handler. The mutex is there to protect from other (Gnome) threads
> that also call malloc/free.
> But if a Gnome thread has the mutex and before it has blocked
> signals, the signal handler is run in parallell on another
> processor, there will be problems. If we move to SYNC_INPUT there
> will be no malloc/free called in the signal handler and we only need
> the mutex to hamdle concurrent access.
The current version would cause such a problem because now
BLOCK_INPUT_ALLOC and UNBLOCK_INPUT_ALLOC are no-op in a signal
handler.
How about just changing the order of lock/unlock and
BLOCK_INPUT/UNBLOCK_INPUT in the previous version of
BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC?
#define BLOCK_INPUT_ALLOC \
do\
{ \
if (pthread_self () == main_thread) \
BLOCK_INPUT;\
pthread_mutex_lock (&alloc_mutex);\
} \
while (0)
#define UNBLOCK_INPUT_ALLOC \
do\
{ \
pthread_mutex_unlock (&alloc_mutex); \
if (pthread_self () == main_thread) \
UNBLOCK_INPUT; \
} \
while (0)
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
YAMAMOTO Mitsuharu skrev: On Thu, 10 Aug 2006 08:20:24 +0200, Jan Djärv <[EMAIL PROTECTED]> said: Hi, I just had a lockup occuring. Here is a backtrace: I've checked in a fix, but I beleive the race condition still exists on multiprocessor machines. I can't see a way to fix that except move to SYNC_INPUT. Maybe I'm missing something, but doesn't adding BLOCK_INPUT around closedir (and opendir) help? In this particular case it would help, but in general the problem is that the signal handler gets called when the main thread is executing in the mutex code (pthread_mutex_unlock). Later when the signal handler tries to get the mutex, it locks up, it is actually not allowed to call mutex functions from a signal handler. The mutex is there to protect from other (Gnome) threads that also call malloc/free. But if a Gnome thread has the mutex and before it has blocked signals, the signal handler is run in parallell on another processor, there will be problems. If we move to SYNC_INPUT there will be no malloc/free called in the signal handler and we only need the mutex to hamdle concurrent access. Jan D. #22 0x080cac12 in XTread_socket (sd=0, expected=1, hold_quit=0xbfabf5ac) at /home/tmp/emacs/src/xterm.c:7067 #23 0x080f90dc in read_avail_input (expected=1) at /home/tmp/emacs/src/keyboard.c:6737 #24 0x080f9283 in handle_async_input () at /home/tmp/emacs/src/keyboard.c:6883 #25 0x080f9317 in input_available_signal (signo=29) at /home/tmp/emacs/src/keyboard.c:6925 #26 #27 0xb795d27d in pthread_mutex_unlock () from /lib/tls/i686/cmov/libpthread.so.0 #28 0xb77a62f5 in free () from /lib/tls/i686/cmov/libc.so.6 #29 0xb77caa08 in closedir () from /lib/tls/i686/cmov/libc.so.6 #30 0x08122c57 in directory_files_internal_unwind (dh=161026626) at /home/tmp/emacs/src/dired.c:137 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
> On Thu, 10 Aug 2006 08:20:24 +0200, Jan Djärv <[EMAIL PROTECTED]> said: >> Hi, I just had a lockup occuring. Here is a backtrace: > I've checked in a fix, but I beleive the race condition still exists > on multiprocessor machines. I can't see a way to fix that except > move to SYNC_INPUT. Maybe I'm missing something, but doesn't adding BLOCK_INPUT around closedir (and opendir) help? YAMAMOTO Mitsuharu [EMAIL PROTECTED] > #22 0x080cac12 in XTread_socket (sd=0, expected=1, hold_quit=0xbfabf5ac) > at /home/tmp/emacs/src/xterm.c:7067 > #23 0x080f90dc in read_avail_input (expected=1) > at /home/tmp/emacs/src/keyboard.c:6737 > #24 0x080f9283 in handle_async_input () at /home/tmp/emacs/src/keyboard.c:6883 > #25 0x080f9317 in input_available_signal (signo=29) > at /home/tmp/emacs/src/keyboard.c:6925 > #26 > #27 0xb795d27d in pthread_mutex_unlock () >from /lib/tls/i686/cmov/libpthread.so.0 > #28 0xb77a62f5 in free () from /lib/tls/i686/cmov/libc.so.6 > #29 0xb77caa08 in closedir () from /lib/tls/i686/cmov/libc.so.6 > #30 0x08122c57 in directory_files_internal_unwind (dh=161026626) > at /home/tmp/emacs/src/dired.c:137 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
