"some versions of perl's garbage collector are buggy and leak memory" #5
Comments
|
you're quite obsessed with that memleak stuff, huh ? |
|
"you're quite obsessed with that memleak stuff, huh ?" Not really. Memleak detection has been part of the automated testing for quite a while, so it is unlikely to show up again for normal usage. I am, however, puzzled why you continue to include such a claim with no evidence. It would be akin to someone writing about jobflow: "jobflow is written in C. Many programs written in C are vulnerable to buffer overflows. These are often used for getting unauthorized access to systems." While all of this is technically true, it gives the impression that there are many known buffer overflow errors in jobflow, and that these pose a security risk. I would find that misleading if there was no evidence to support that claim. I have only found a single buffer overflow error in your code, and I do not think that error can be exploited by an attacker: I hope you will find this report helpful and hope that you will either back up your claim with evidence or remove the claim. |
thanks to ole tange for reporting the issue.
echo a | ./jobflow.out -exec echo {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {}
=================================================================
==5173==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd67da6970 at pc 0x7fb7c72b3904 bp 0x7ffd67d96740 sp 0x7ffd67d95ee8
WRITE of size 1 at 0x7ffd67da6970 thread T0
#0 0x7fb7c72b3903 in __asan_memcpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c903)
#1 0x4070e1 in substitute_all /home/rofl/jobflow/jobflow.c:544
#2 0x407b1b in dispatch_line /home/rofl/jobflow/jobflow.c:635
#3 0x408704 in main /home/rofl/jobflow/jobflow.c:752
#4 0x7fb7c617082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#5 0x401f18 in _start (/home/rofl/jobflow/jobflow.out+0x401f18)
Address 0x7ffd67da6970 is located in stack of thread T0 at offset 65888 in frame
#0 0x407658 in dispatch_line /home/rofl/jobflow/jobflow.c:588
This frame has 6 object(s):
[32, 48) 'line_b'
[96, 112) 'source_storage'
[160, 176) '<unknown>'
[224, 240) 'tilLastDot'
[288, 304) '<unknown>'
[352, 65888) 'subst_buf' <== Memory access at offset 65888 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 __asan_memcpy
|
good catch, thanks for your report. |
Thanks for the update.
Most of your claims about GNU Parallel are easy to verify. (E.g. run
time parallel echo ::: 1to see the startup time andseq 1000 | time -v parallel trueto see memory usage).But claiming that Perl's buggy garbage collector is a disadvantage to GNU Parallel is not easy to verify. So if you want to use correct claims, I will encourage you to link to an example that shows the current version of GNU Parallel being affected by Perl's buggy garbage collector.
Having run GNU Parallel on many different architectures and many different versions of Perl (version 5.8.4..5.26.1 on armv7l, sparc, armv6hl, alpha, mips) I have never seen the current version of GNU Parallel being affected by Perl's buggy garbage collector, so I am quite interested in seeing the exact situation in which that happens.
So may I suggest you include a link to a reproducible example showing this actually happening?
The text was updated successfully, but these errors were encountered: