: libobjc
Assignee: unassigned at gcc dot gnu.org
Reporter: max at cert dot cx
Hi,
I have found interesting examples of dynamic memory allocation use in libobjc
libobjc/selector.c -
SEL *
sel_copyTypedSelectorList (const char *name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61332
--- Comment #2 from Maksymilian A ---
It seems that we have two problems here:
1 The first is memory allocation without GC_malloc (when GC used)
2 If OBJC_WITH_GC is not definied, objc_malloc() also check result of malloc()
-
objc_malloc (
++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at cert dot cx
Hi,
Tested on GCC 4.8.1
--
#include
using namespace std;
int main (int argc, char *argv[])
{
regex r(argv[1]);
return 0;
}
--
# g++ c11RE.cpp -o c11RE -std=c++11 -Wall
# ./c11RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #2 from Maksymilian A ---
Sorry for mistake.
Could you check this again ?
cx@cx:~/REstd11/kozak5$ ~/gcc49/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/cx/gcc49/bin/g++
COLLECT_LTO_WRAPPER=/home/cx/gcc49/libexec/gcc/x86_64-unkno
++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at cert dot cx
cx@cx:~/REstd11/kozak5$ ~/gcc49/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/cx/gcc49/bin/g++
COLLECT_LTO_WRAPPER=/home/cx/gcc49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #5 from Maksymilian Arciemowicz ---
Thanks for feedback. I'm going verify this on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #6 from Maksymilian Arciemowicz ---
@Jonathan: true but check this case
cx@cx:~/REtrunk/kozak5$ ~/gccTRUNK/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/cx/gccTRUNK/bin/g++
COLLECT_LTO_WRAPPER=/home/cx/gccTRUNK/libexec/gcc/x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #8 from Maksymilian Arciemowicz ---
(In reply to Tim Shen from comment #7)
> "(.*{100}{100}{100})" seems to be a stack overflow. It's because regex
> executor uses recursion. It could be fixed (not segfault but memory
> exhaustion) by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #10 from Maksymilian Arciemowicz ---
There is also one other alternative like this
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/regex/regcomp.c.diff?r1=1.29&r2=1.30&f=h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #6 from Maksymilian Arciemowicz ---
> Do you have any other testcases?
for trunk? maybe you have to use ::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #8 from Maksymilian Arciemowicz ---
> there's no memory problem, it just takes exponentially long time to run
> (which is expected when using backtracking).
call it cpu resource exhaustion (CWE-400)
>
> To avoid it, you can use Tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #12 from Maksymilian Arciemowicz ---
Ups. Check this (.*{100}{300})
gcc version 4.10.0 20140701 (experimental) (GCC)
Starting program: /home/cx/REtrunk/kozak5/t3 '(.*{100}{300})'
Program received signal SIGSEGV, Segmentatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
--- Comment #4 from Maksymilian Arciemowicz ---
cpu exhaustion not eliminated
PoC: (.*{100}{200}findme)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #13 from Maksymilian Arciemowicz ---
@Tim: do you need help?
14 matches
Mail list logo
