Date: Fri, 1 Aug 1997 02:24:07 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: andreas@klemm.gtn.com (Andreas Klemm) Cc: current@freebsd.org Subject: Re: httpd in free(): warning: modified (page-) pointer. Message-ID: <199708010624.CAA12780@skynet.ctr.columbia.edu> In-Reply-To: <19970801065632.28286@gtn.com> from "Andreas Klemm" at Aug 1, 97 06:56:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Andreas Klemm had to walk into mine and say: > Am using apache-stable on FreeBSD-2.2-STABLE and 3.0-CURRENT > > compiled in newest php version. > > On FreeBSD-2.2 everything is fine calling pgp html pages. > On FreeBSD-current I get the following warning as root > logged in: > > httpd in free(): warning: modified (page-) pointer. > httpd in free(): warning: modified (page-) pointer. > httpd in free(): warning: modified (page-) pointer. > httpd in free(): warning: modified (page-) pointer. > > This message only appears, if I load a .phtml page, > so I think it indicates some trouble in the php perl > module I compiled in. Between apache and perl, I think it would be an incredible coincidence if there wasn't a bug in the code somewhere. > But why only on -current ??? What to do next ??? The fact that malloc()/free() only complains on FreeBSD-current does not mean that the bug isn't also present on FreeBSD-2.2.x. It's there too: you just don't see it. It may be that it only shows up on current due to some change in the malloc code. However, there is most certainly a bug in the pgp module you compiled into apache (or there's a bug in apache which is triggered by the extra module). If the code is supported by someone, write them a note and tell them it's buggy. There are a couple of things you can do to try tracking down the problem: - Grab the malloc.c module from the libc source and compile it directly into apache. Build the whole binary with -g. (This will override the malloc in libc, which is not compiled with debug symbols.) Run apache with gdb and set a breakpoint in the malloc code where this error message occurs. Then reproduce the condition that causes the error; gdb will stop the server at the breakpoint and you can get a function call trace which will hopefully show you the error. - Compile apache with the Electric Fence 2.0.5 debugging malloc library. Compile with -g, as before, link with -lefence and run the server normally. The odds are that the problem here is heap corruption; with Electric Fence, the instant you stray out of bounds of a buffer allocated with malloc(), the program will get smacked with a SIGBUS and die, leaving a core dump behind. The core can be used with gdb to locate the offending code. Caveats: o With our gdb, it is sometimes difficult to use a core dump to properly debug things: you will be able to get a stack trace and locate the exact line in the source where the program died, however not all of the environment is preserved: variables are not properly reloaded with the values they posessed when the crash took place. If the program crashes while being run in gdb, then you can examine variables and memory contents with no problems, but trying to do it with just the crash dump and the executable doesn't seem to work. (It seems to work with kernel crash dumps though.) I wish it did; it would make my life a lot easier. o Electric Fence works by using mmap() to allocate memory instead of brk()/sbrk(). To trap out of bounds references, it allocates an extra page of memory immediately after the memory requested with malloc()/calloc()/etc and uses mprotect() to disallow read and write access to it. In this way, you use the MMU itself to signal bad accesses: the instant an instruction is executed that tries to reference the protected page, a trap is generated and your program dies with a SIGBUS. If the executable and libefence.a are both compiled with -g, you can then use gdb to locate the exact line of source where the invalid reference took place. The downside to this is that the malloc() in libefence.a takes longer to work and uses more memory than normal. If you can trip the bug right away, then this probably won't pose any problems, but it can get a bit clumsy with programs that run for a long time or allocate lots of memory. Before you ask, Electric Fence is available at ftp.pixar.com:/pub/bruce. You need to fiddle with it slightly to compile it on FreeBSD, but in general I find it works quite well. I've been using it while working on my NIS+ code and once or twice on ypserv, and it's helped a lot. More people should make use of it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708010624.CAA12780>