Opened 11 years ago

Closed 11 years ago

#3128 closed bug (fixed)

sh leaks memory

Reported by: bhaible Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

When executing large configure scripts, the 'sh' process gets bigger and bigger.

While running a configure script in tight memory situation, I got an application crash. Clicking on the "Debug" button of the error dialog, I was presented a gdb session the shell that was executing the configure script. At the top, function fork().

To reproduce:

  1. Start Haiku in QEMU with 256 MB RAM allocated to it,
  1. Open a Terminal.
  1. $ wget http://www.haible.de/bruno/gnu/testdir3.tar.gz
  1. $ tar xvfz testdir3.tar.gz
  1. $ cd testdir3
  1. $ ./configure --host=i586-pc-haiku --build=i586-pc-haiku

--prefix=/boot/home/config CPPFLAGS="-Wall" 2>&1 | tee log1

  1. Repeatedly do "ps". After some time, the "sh" process uses

40 MB user memory and 100 MB kernel memory. And it gets more and more... Until either a message "Out of memory" or a crash. Such a shell script should be executable in 10 MB.

Change History (3)

comment:1 Changed 11 years ago by bonefish

Component: - GeneralSystem/Kernel

I don't see the growing shell memory size here. At least ProcessController constantly shows a little more than 400 KB for the terminal's login shell the whole time, and about 1.2 MB for the configure shell while it runs. I do see an increase in kernel memory usage though, suggesting a memory leak in the kernel.

The leak checking suggests that memory allocated in arch_vm_translation_map_init_map() is leaked, so supposedly the ref-counting doesn't work as it should. Will look into this later tonight, unless someone beats me to it.

comment:2 Changed 11 years ago by bonefish

Owner: changed from axeld to bonefish
Status: newassigned

comment:3 Changed 11 years ago by bonefish

Resolution: fixed
Status: assignedclosed

The kernel leak is fixed in hrev28644. Please reopen, if you can actually reproduce that the shell is leaking memory.

Note: See TracTickets for help on using tickets.