GNU bug report logs - #451
23.0.60; x-gtk-map-stock destroys match data

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 451 in the body.
You can then email your comments to 451 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Nick Roberts <nickrob <at> snap.net.nz>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; x-gtk-map-stock destroys match data
Date: Fri, 20 Jun 2008 14:38:25 +1200 (NZST)

In the event loop (?), update_frame_tool_bar calls x-gtk-map-stock (in
x-win.el) which uses string-match.  This changes the match data that I need for
my application.  I don't know what the rules are about using string-match from
C code but as a minimum x-gtk-map-stock should wrap save-match-data around
the call to it.


In GNU Emacs 23.0.60.19 (i686-pc-linux-gnu, GTK+ Version 2.10.11)
 of 2008-06-20 on kahikatea.snap.net.nz
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
configured using `configure  'CFLAGS=-g3' '--enable-font-backend''

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: en_NZ.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Change Log

Minor modes in effect:
  isearch-buffers-minor-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: (only . t)

Recent input:
<backspace> <backspace> <backspace> <tab> C-x C-s <down-mouse-1> 
<mouse-1> C-x C-b <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<down-mouse-2> <mouse-2> <help-echo> C-x C-f <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> s r c / s t <tab> 
<backspace> <backspace> <return> <help-echo> <next> 
<next> C-h f g t x - s t <tab> C-g C-h C-h C-g <down-mouse-1> 
<mouse-movement> <mouse-1> <help-echo> <down-mouse-1> 
<mouse-1> C-x <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <search-documentation> <find-any-object-by-name> 
C-g <down-mouse-1> <mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <search-documentation> <find-any-object-by-name> 
s t o c k <return> <help-echo> <down-mouse-2> <mouse-2> 
<help-echo> <help-echo> <down-mouse-2> <mouse-2> <down-mouse-1> 
<mouse-1> <help-echo> <down-mouse-1> <mouse-1> C-s 
g t k <down-mouse-1> <mouse-1> f <help-echo> <down-mouse-1> 
<mouse-1> C-s c a l l 1 C-s C-s <down-mouse-1> <mouse-1> 
C-M-S-a C-S-s C-S-s <down-mouse-1> <mouse-1> <prior> 
<prior> <prior> <next> <prior> <help-echo> <down-mouse-2> 
<mouse-2> <help-echo> <prior> <switch-frame> <down-mouse-1> 
<mouse-1> <switch-frame> <down-mouse-1> <mouse-movement> 
<mouse-1> <down-mouse-1> <mouse-1> C-S-x V G <help-echo> 
<down-mouse-1> <mouse-1> <help-echo> <down-mouse-1> 
<mouse-1> C-s c a l l 1 C-a C-r C-r <down-mouse-1> 
<mouse-1> <help-echo> <down-mouse-1> <mouse-1> <down-mouse-1> 
<mouse-1> C-s C-s <help-echo> <down-mouse-1> <mouse-1> 
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> C-s 
C-s C-s <help-echo> <switch-frame> <down-mouse-1> <mouse-movement> 
<mouse-1> M-x r e p o r t SPC C-g <switch-frame> <down-mouse-1> 
<mouse-1> <down-mouse-1> <mouse-movement> <mouse-1> 
<prior> <prior> <prior> <prior> <prior> <next> <prior> 
<prior> <down-mouse-1> <mouse-1> C-s C-w C-w C-w C-w 
C-s C-r C-r C-r <down-mouse-1> <mouse-1> C-M-a C-s 
C-s C-s C-s <next> <next> <next> <prior> <prior> <down-mouse-1> 
<mouse-1> C-s c a l l 1 <down-mouse-1> <mouse-1> C-s 
C-w C-r C-r C-r C-s C-s <switch-frame> <down-mouse-1> 
<mouse-1> M-x r e p o r t SPC e m SPC SPC <return>

Recent messages:
Type C-x 4 C-o RET to restore the other window.
Mark saved where search started [3 times]
Annotating...
Mark saved where search started
Redisplaying annotation...done (Spanned from 1979.6 to 5.6 days old)
Mark set
Annotating... done
Mark saved where search started [2 times]
Quit
Mark saved where search started [4 times]


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nick Roberts <nickrob <at> snap.net.nz>
Cc: 451 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#451: 23.0.60; x-gtk-map-stock destroys match data
Date: Fri, 20 Jun 2008 10:28:30 -0400

> In the event loop (?), update_frame_tool_bar calls x-gtk-map-stock (in
> x-win.el) which uses string-match.  This changes the match data that
> I need for my application.  I don't know what the rules are about
> using string-match from C code but as a minimum x-gtk-map-stock should
> wrap save-match-data around the call to it.

The match-data is a very volatile piece of data.  So while you may be
right, I think it's more likely that the problem is in your code
(i.e., your code should save the match-data itself if it needs to use
it after some non-trivial code has been run, and by "trivial" I *really*
mean trivial).


        Stefan

Message #20 received at 451 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Nick Roberts <nickrob <at> snap.net.nz>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 451 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#451: 23.0.60; x-gtk-map-stock destroys match data
Date: Sat, 21 Jun 2008 11:01:17 +1200

 > > In the event loop (?), update_frame_tool_bar calls x-gtk-map-stock (in
 > > x-win.el) which uses string-match.  This changes the match data that
 > > I need for my application.  I don't know what the rules are about
 > > using string-match from C code but as a minimum x-gtk-map-stock should
 > > wrap save-match-data around the call to it.
 > 
 > The match-data is a very volatile piece of data.  So while you may be
 > right, I think it's more likely that the problem is in your code
 > (i.e., your code should save the match-data itself if it needs to use
 > it after some non-trivial code has been run, and by "trivial" I *really*
 > mean trivial).

I don't think that's right.  The problem goes away if I remove the tool bar.
If I do:

(string-match "ox" "The quick lazy fox jumped")

in the *scratch* buffer then

(match-beginning 0)
(match-end 0)

give me false values immediately afterwards.

Presumably update_frame_tool_bar gets called in between the evaluations.  I'm
not sure exactly why it's called but I have:

(add-hook 'gdb-mode-hook
'(lambda ()
   (tool-bar-mode 1)
   (if (eq window-system 'x)
       (define-key-after gud-tool-bar-map [function-step]
	 '(menu-item "Step outer" gud-function-step
		     :image (image :type xpm
		     :file "/home/nickrob/emacs/etc/images/jump-to.xpm")
		     :enable (not gud-running)
		     :visible (memq gud-minor-mode '(gdbmi gdba)))))))

in my .emacs


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #30 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Nick Roberts <nickrob <at> snap.net.nz>
Cc: 451 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#451: 23.0.60; x-gtk-map-stock destroys match data
Date: Fri, 20 Jun 2008 22:27:39 -0400

> I don't think that's right.  The problem goes away if I remove the tool bar.
> If I do:

> (string-match "ox" "The quick lazy fox jumped")

> in the *scratch* buffer then

> (match-beginning 0)
> (match-end 0)

> give me false values immediately afterwards.

What do you mean "immediately afterwards"?  If you get back to the
toplevel in the mean time, the "immediately" actually runs a crapload of
code.  I.e. it's anything but "immediate".  Your expectation is
just wrong.

> Presumably update_frame_tool_bar gets called in between the evaluations.

This and megabytes of code, yes.


        Stefan

Message #40 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Nick Roberts <nickrob <at> snap.net.nz>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 451 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#451: 23.0.60; x-gtk-map-stock destroys match data
Date: Sat, 21 Jun 2008 17:07:54 +1200

> > I don't think that's right.  The problem goes away if I remove the tool bar.
> > If I do:
> > (string-match "ox" "The quick lazy fox jumped")
> > in the *scratch* buffer then
> > (match-beginning 0)
> > (match-end 0)
> > give me false values immediately afterwards.

> What do you mean "immediately afterwards"?  If you get back to the
> toplevel in the mean time, the "immediately" actually runs a crapload of
> code.  I.e. it's anything but "immediate".  Your expectation is
> just wrong.

I meam using C-x C-e.  It looks like you are indeed right and that 
match-beginning and match-end can only be used programmatically.  I was
using edebug and getting strange values evaluating them (manually).  I
thought I had done that before - but clearly not.

Sorry but I don't know how to close the bug report.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Message #50 received at 451-close <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 451-close <at> debbugs.gnu.org
Subject: Re: bug#451: 23.0.60; x-gtk-map-stock destroys match data
Date: Sat, 21 Jun 2008 15:46:05 -0400

> I meam using C-x C-e.  It looks like you are indeed right and that 
> match-beginning and match-end can only be used programmatically.  I was
> using edebug and getting strange values evaluating them (manually).  I
> thought I had done that before - but clearly not.

In edebug, if you use `e' you should be able to use match-beginning and
match-end.  But with M-: it's hopeless.

> Sorry but I don't know how to close the bug report.

Just send it to <bugnb>-close@... as I've done here.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.