Bug 350896

Summary:	make module_install fails - depmod cannot allocate memory
Product:	[openSUSE] openSUSE 10.3	Reporter:	Forgotten User qMyteedNxa <forgotten_qMyteedNxa>
Component:	Kernel	Assignee:	Michal Marek <mmarek>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	jeffm
Version:	Final
Target Milestone:	---
Hardware:	32bit
OS:	openSUSE 10.3
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:
Bug Blocks:	562232

Description Forgotten User qMyteedNxa 2007-12-28 14:35:18 UTC

I tried building a vanilla kernel (2.6.24rc6) on my opensuse 10.3 box because i like to compare if an error with 2.6.24rc6-suse-kotd kernel is reproducable with vanilla kernel.

when i do "make modules_install" the process runs for a while and then fails with "Warning: Can`t read module ......: Cannot allocate memory
Fatal: Memory allocation failure depmod.c line 119: malloc(sizeof *new + strlen(name) + 1). 
make: *** [_modinst_post] Error 1

My box has 512MB ram.

I startet make a second time and watched growth of depmod process, and it was around 850MB VSZ, 350MB RSS when it failed.

Any clue why depmod dies with out of memory error ?

Comment 1 Jeff Mahoney 2008-01-02 22:53:37 UTC

There's probably an unterminated array somewhere that it's traversing and hasn't managed to hit a NULL where it expects one.

Can you see if -git7 shows the same problem?

If so, please provide the output of strace depmod -ae -F Systemp.map from the kernel build directory. It should at least help narrow down which module is causing it to go nuts.

Comment 2 Forgotten User qMyteedNxa 2008-01-03 00:02:16 UTC

apparently, suse seems to set CONFIG_DEBUG_INFO=y , and this triggers the issue.

i`m able to make modules_install with CONFIG_DEBUG_INFO=n

it seems not to be a suse issue but a depmod issue - i had sent this to lkml, too and got some response from depmod maintainer:

see 
http://marc.info/?l=linux-kernel&m=119893605611759&w=2
http://marc.info/?l=linux-kernel&m=119889263505955&w=2

will try your hint, though (when i`m back at my system)


thanks for the feedback, jeff!

Comment 3 Jeff Mahoney 2008-01-03 01:26:05 UTC

Huh, that's interesting. I think that our kernel RPMs take advantage of some RPM magic here. Our raw configs (ie: not in /proc/config.gz) don't actually set CONFIG_DEBUG_INFO - it's set in the RPM, and then the debug sections are stripped off the binaries to make the -debuginfo package. This might even happen before make modules_install is run, but I'm not an RPM guru.

Now, I agree there's a bug here, and I'm going to pass it on to our module-init-tools maintainer for review. The thing is that we publish a vanilla flavor for all our kernel RPMs.

So, you'll have your kernel-default RPM, but there is also a kernel-vanilla.

It is identical to the vanilla kernel with the exception that there are a few patches applied to get it to build in our environment. The section-conflict ones are because the compiler on ia64 complains when module parameter functions are static. powerpc-needs-uboot is only for powerpc, and gcc43 workaround will be a no-op if you're not using gcc 4.3. If you were, you would have run into build failure relating to time and an unresolvable __udivdi3 call.

Here's the current list:
patches.kernel.org/powerpc-needs-uboot
patches.kernel.org/gcc43-workaround.diff
patches.kernel.org/ia64-jprobe-return-section-conflict.diff
patches.kernel.org/gameport-section-conflict.diff
patches.kernel.org/psmouse-section-conflict.diff
patches.kernel.org/ipmi-section-conflict.diff

I understand that you may be wary about using it, but that's your call. For the time being, your only option may be to either strip and build your own debuginfo tree or to disable CONFIG_DEBUG_INFO.

Comment 4 Michal Marek 2008-03-25 16:09:09 UTC

I'm currently testing a patch that should reduce depmod usage in all cases. It should fix your issue too.

*** This bug has been marked as a duplicate of bug 371966 ***