[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #38616] memory leak in regexprep
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #38616] memory leak in regexprep |
Date: |
Wed, 10 Apr 2013 20:12:08 +0000 |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 |
Follow-up Comment #5, bug #38616 (project octave):
I started by attempting to reproduce the segfault you describe with this
code.
s="0123456789";
for i=1:21, s=cstrcat(s,s);,endfor
s = regexprep(s,'0','2');
s = regexprep(s,'1','2');
s = regexprep(s,'2','3');
Unfortunately this works fine for me with the system I have available for
testing (3.6.4 on x86_64 Linux).
Are you running on a 32-bit or 64-bit architecture? This would affect the
size of pointers which could be a problem.
Second, the final segfault is replacing 3/10 of the entries in s with a new
value. 3/10 of the size of s is 6291456 or approximately 2^22.6. So in order
to untangle things, does the following standalone code also cause a segfault?
s = repmat ('2', 1, 2^23);
s = regexprep (s, '2', '3');
Finally, would it be possible for you to compile with debugging and run under
gdb to produce a backtrace?
Something like the following should do it assuming you are using a Bourne sh.
CFLAGS="-g -O0"
CXXFLAGS="-g -O0"
# That is the letter 'O' followed by the numerical digit zero.
export CFLAGS
export CXXFLAGS
./configure --your_options_here
make
# The following runs the newly built octave under gdb
run-octave -g
s="0123456789";
for i=1:21, s=cstrcat(s,s);,endfor
s = regexprep(s,'0','2');
s = regexprep(s,'1','2');
s = regexprep(s,'2','3');
# When this produces a segmentation fault, get a backtrace with 'bt'
bt
# And attach the results to this bug report.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?38616>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #38616] memory leak in regexprep,
Rik <=