rakitzis / rc

rc shell -- independent re-implementation for Unix of the Plan 9 shell (from circa 1992)
Other
250 stars 23 forks source link

Valgrind `Invalid read` error on trip.rc #99

Closed borkovic closed 1 week ago

borkovic commented 3 months ago

Running

valgrind -v --leak-check=full --show-leak-kinds=all ./rc  -p < trip.rc

gives several memory leaks and the error shown below.

The git commit is 2e95de3.

Expand to see Valgrind log ``` 247341 ==5774== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) 247342 ==5774== 247343 ==5774== 1 errors in context 1 of 1: 247344 ==5774== Invalid read of size 2 247345 ==5774== at 0x4E702BD: getenv (getenv.c:88) 247346 ==5774== by 0x4E67E2D: guess_category_value (dcigettext.c:1340) 247347 ==5774== by 0x4E67E2D: __dcigettext (dcigettext.c:555) 247348 ==5774== by 0x4EC3CDD: strerror_r (_strerror.c:72) 247349 ==5774== by 0x4EC3C1E: strerror (strerror.c:31) 247350 ==5774== by 0x40F3A5: uerror (utils.c:26) 247351 ==5774== by 0x4114FA: rc_access (which.c:54) 247352 ==5774== by 0x4116AC: which (which.c:104) 247353 ==5774== by 0x403363: exec (exec.c:63) 247354 ==5774== by 0x4104F2: walk (walk.c:43) 247355 ==5774== by 0x40952E: doit (input.c:318) 247356 ==5774== by 0x40AA74: main (main.c:141) 247357 ==5774== Address 0x5228b60 is 0 bytes inside a block of size 64 free'd 247358 ==5774== at 0x4C2AF5D: free (vg_replace_malloc.c:540) 247359 ==5774== by 0x40B320: efree (nalloc.c:138) 247360 ==5774== by 0x407949: get_var_place (hash.c:156) 247361 ==5774== by 0x40F5B3: varassign (var.c:20) 247362 ==5774== by 0x40679F: assign (glom.c:165) 247363 ==5774== by 0x410A81: walk (walk.c:172) 247364 ==5774== by 0x41050F: walk (walk.c:46) 247365 ==5774== by 0x40166E: funcall (builtins.c:89) 247366 ==5774== by 0x403497: exec (exec.c:102) 247367 ==5774== by 0x4104F2: walk (walk.c:43) 247368 ==5774== by 0x40952E: doit (input.c:318) 247369 ==5774== by 0x40AA74: main (main.c:141) 247370 ==5774== Block was alloc'd at 247371 ==5774== at 0x4C29E63: malloc (vg_replace_malloc.c:309) 247372 ==5774== by 0x40B27F: ealloc (nalloc.c:118) 247373 ==5774== by 0x40DB0D: mprint (print.c:365) 247374 ==5774== by 0x40F962: varlookup_string (var.c:107) 247375 ==5774== by 0x4080CC: makeenv (hash.c:293) 247376 ==5774== by 0x4033AB: exec (exec.c:71) 247377 ==5774== by 0x4104F2: walk (walk.c:43) 247378 ==5774== by 0x40952E: doit (input.c:318) 247379 ==5774== by 0x40AA74: main (main.c:141) 247380 ==5774== 247381 ==5774== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ```

With some local modifications, I get a very similar valgrind error in getenv() invoked from yyparse(). The block is allocated and freed from similar stacks:

rakitzis commented 2 weeks ago

Is this issue still open? I ran valgrind at the tip of the tree and see:

==2503== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

The leak summary also shows reachable bytes, which as far as I know are simply bytes not freed by the time exit() is called.

borkovic commented 2 weeks ago

I tried running valgrind inside an ARM MacOS Ubuntu docker. No errors, just leaks. I tried again on an AWS x86 CentOS instance (original run was there too). Still showing the same errors.

27ed71e [rakitzis/master] Merge pull request #108 from jpco/master

Which platform did you use?

rakitzis commented 2 weeks ago

Ubuntu noble, Intel NUC.

rakitzis commented 2 weeks ago

What version of glibc is installed on your CentOS instance? Would be good to isolate this to e.g., a malloc behavior.

borkovic commented 2 weeks ago

In AWS CentOS instance (that has the problem) glibc version is 2.17: gnu_get_libc_version() returns 2.17.

src/rc $ ldd --version
ldd (GNU libc) 2.17
src/rc $  /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.

In the MacOS Docker (Ubuntu Linux) that does not have this problem glibc is 2.35:

DOCKER-22.04(7) : work2/ $ /lib/aarch64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.35-0ubuntu3.8) stable release version 2.35.
rakitzis commented 2 weeks ago

Seems like 2.17 is many versions back. Is this a glibc bug?

borkovic commented 1 week ago

True. Hard to say.

rakitzis commented 1 week ago

I'll close this for now. If you have a repro that is an rc use-after-free bug, please reopen this issue.