RE: stack overflow in regexp matcher with gdb

[Maury, Olivier]

Well I'm not fluent in Lisp so it's difficult for me to really understand what 
it's doing. But, based on the trace I got and what I can guess from the 
gdb-ui.el file, I suppose that function is here to get the value of each local 
parameter of the function and to print that into the "Locals" frame buffer. 
So when, as it is the case here, you have a very very large number of local 
variables (something around 2500 variables with some of them that are double 
arrays on the stack and with significantly long names)... it seems it fails.
I wish I knew more about Lisp in order to propose a fix... Assuming my guess is 
correct, if we could, for example, parameterize the number of variables that we 
can monitor in the "Locals" buffer then we could just process only a part of 
that huge list and maybe it wouldn't fail or take ages to refresh ?

Olivier

-----Original Message-----
From: Stefan Monnier [mailto:monnier@iro.umontreal.ca] 
Sent: Thursday, November 14, 2013 20:31
To: Maury, Olivier
Cc: help-gnu-emacs@gnu.org
Subject: Re: stack overflow in regexp matcher with gdb

> I tried with the 24.3 version of emacs and the gdb -i=mi interface. It 
> seems it works a little bit better (doesn't fail with that kind of 
> error). However when I do a "next" the first one is ok but the second 
> "next" is very slow and then it's ok again and then it's very slow 
> again, etc... and from time to time the gdb prompt is no longer 
> printed even though I can still enter gdb commands...

Hmm... performance bugs can be even worse to track down :-(

> Using gud-gdb with the 24.3 version of emacs seems even more weird as 
> it doesn't show the source files I've stop in...

That's odd as well: for me it does jump to the source.  `gud-gdb' should be the 
"safe fallback", so please report a bug about this, providing as much details 
as you can.

>   looking-at(",value=\\(\".*\"\\).*?}")

Indeed, this regexp is problematic.  Do you have some idea what the text can be 
between the quotes?
IOW can we use (looking-at ",value=\\(\"[^\"]*\"\\).*?}") instead (which would 
eliminate the backtracking), or is the a risk of the value containing a " 
somewhere (and if so, how is it quoted?)?

The 24.3 code is pretty different, but I see the same kind of regexp, so the 
same problem is probably present as well.


        Stefan