RE: stack overflow in regexp matcher with gdb

["Maury, Olivier" <Olivier_Maury@mentor.com>]

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