bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7012: 24.0.50; bidi: crash while selecting region using mouse in X11


From: Thamer Mahmoud
Subject: bug#7012: 24.0.50; bidi: crash while selecting region using mouse in X11
Date: Mon, 20 Sep 2010 16:04:11 +0300

Eli Zaretskii writes:
 > Thanks.  Unfortunately, I cannot reproduce this on my machine (which
 > runs MS-Windows).
 > 
 > How many times do you need to move the mouse back and forth before it
 > crashes? 

I did more testing, and I only had to drag the mouse once.  AFAICT,
it's not the multiple highlighting that is causing this crash, but
rather dragging the mouse upward (by pressing and holding the
left-button) while trying to position cursor on an Arabic line that
starts with L2R characters embedded in an R2L context (like the 2nd
line in the testcase).

For instance, if I have the following content in the middle of a
buffer:

‏
a ‏abcdef

Emacs crashes when dragging the mouse from any point below while
moving upward to position cursor between "abcdef".

Moreover, this crash seems specific to Arabic and reordered Latin text
using RLM (like the above example).  I couldn't reproduce this using
Hebrew.

 > If you can consistently reproduce the crash with the recipe you
 > posted, then please type "pr *bidi_it" in frame #1 and post the
 > results here.  Thanks.

Did you mean "p *bidi_it"?  (sorry, I'm not familiar with what "pr" is
and it returned an error).  Here is the output of both commands anyway
using the earlier testcase.

Thanks.

(gdb) p *bidi_it
$6 = {
  bytepos = 14, 
  charpos = 10, 
  ch = 110, 
  ch_len = 1, 
  type = STRONG_L, 
  type_after_w1 = STRONG_L, 
  orig_type = STRONG_L, 
  resolved_level = 2, 
  invalid_levels = 0, 
  invalid_rl_levels = -1, 
  prev_was_pdf = 0, 
  prev = {
    bytepos = 13, 
    charpos = 9, 
    type = STRONG_L, 
    type_after_w1 = STRONG_L, 
    orig_type = STRONG_L
  }, 
  last_strong = {
    bytepos = 13, 
    charpos = 9, 
    type = STRONG_L, 
    type_after_w1 = STRONG_L, 
    orig_type = STRONG_L
  }, 
  next_for_neutral = {
    bytepos = 10, 
    charpos = 6, 
    type = UNKNOWN_BT, 
    type_after_w1 = UNKNOWN_BT, 
    orig_type = UNKNOWN_BT
  }, 
  prev_for_neutral = {
    bytepos = 13, 
    charpos = 9, 
    type = STRONG_L, 
    type_after_w1 = STRONG_L, 
    orig_type = STRONG_L
  }, 
  next_for_ws = {
    bytepos = 0, 
    charpos = 0, 
    type = UNKNOWN_BT, 
    type_after_w1 = UNKNOWN_BT, 
    orig_type = UNKNOWN_BT
  }, 
  next_en_pos = -1, 
  ignore_bn_limit = 0, 
  sor = R2L, 
  scan_dir = -1, 
  stack_idx = 0, 
  level_stack = {{
      level = 1, 
      override = NEUTRAL_DIR
    }, {
      level = 0, 
      override = NEUTRAL_DIR
    } <repeats 63 times>}, 
  first_elt = 0, 
  paragraph_dir = R2L, 
  new_paragraph = 0, 
  separator_limit = -1
}

(gdb) pr *bidi_it
(
Program received signal SIGSEGV, Segmentation fault.
0x0820684e in print_object (obj=14, printcharfun=138920914, escapeflag=1) at 
print.c:1864
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.
When the function is done executing, GDB will silently stop.


-- 
Thamer







reply via email to

[Prev in Thread] Current Thread [Next in Thread]