[PATCH] WIN9x - Apache has caused an error in LIBAPR.DLL

[Mladen Turk <mt...@mappingsoft.com>]

Hi all,

I think that someone noticed that when shutting down the Apache on WIN9x
platform you get the exclamation error box stating : "Apache has caused an
error in LIBAPR.DLL ...." ?

Here is a small patch that solves that problem.

The error is in locks/win32/locks.c lock_cleanup function that gets the NULL
as a function parameter. I wasn't able to track the source of the call that
send the NULL value to apr_lock_destroy but here is the patch that checks if
the function value is NULL and returns not APR_SUCCESS in such a case

--- locks.c.old	Thu Jul 19 17:26:36 2001
+++ locks.c	Sat Aug 11 16:03:34 2001
@@ -63,6 +63,8 @@
 {
     apr_lock_t *lock = lock_;

+	if (!lock)
+	    return APR_EINVAL;
     switch (lock->type)
     {
     case APR_MUTEX:


Well, the code speaks for itself

MT.

RE: [PATCH] WIN9x - Apache has caused an error in LIBAPR.DLL

[Mladen Turk <ml...@mail.inet.hr>]

> -----Original Message-----
> From: Cliff Woolley [mailto:cliffwoolley@yahoo.com]
> Sent: Saturday, August 11, 2001 6:28 PM
> To: Mladen Turk
> Cc: APR Dev List
> Subject: Re: [PATCH] WIN9x - Apache has caused an error in LIBAPR.DLL
>
>
> On Sat, 11 Aug 2001, Mladen Turk wrote:
>
> > I think that someone noticed that when shutting down the Apache on WIN9x
> > platform you get the exclamation error box stating : "Apache
> has caused an
> > error in LIBAPR.DLL ...." ?
>
> I'm amazed that you got Apache to work even that well on Win9x.  I was
> under the impression that it was totally fubar at the moment.  <shrug>
>
> > The error is in locks/win32/locks.c lock_cleanup function that
> gets the NULL
> > as a function parameter. I wasn't able to track the source of
> the call that
> > send the NULL value to apr_lock_destroy but here is the patch
> that checks if
> > the function value is NULL and returns not APR_SUCCESS in such a case
>
> -1.  APR does not typically check parameter correctness.  We leave it up
> to the caller to give us a parameter that's valid on the assumption that
> if they can't manage to do that then they might not check to see if we
> gave them an error return code either.  Besides, if they pass in NULL,
> it's easier to debug a SEGV than a return value that gets either ignored
> or propagated to some time in the future when it's likely harder to figure
> out exactly what happened.
>
> Thanks for looking into this, but we need to keep looking for the source
> of the NULL parameter rather than bandaiding it.

I found the bugger.
It's in the mpm_winnt.c, and the couse is the queue lock that gets
initialized only on WINNT, don't know if it should on WIN9x too?
Well here is the patch:

--- mpm_winnt.c.old	Sat Aug  4 09:20:14 2001
+++ mpm_winnt.c	Sat Aug 11 20:12:32 2001
@@ -1167,7 +1167,8 @@

     CloseHandle(allowed_globals.jobsemaphore);
     apr_lock_destroy(allowed_globals.jobmutex);
-    apr_lock_destroy(qlock);
+    if (osver.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS)
+        apr_lock_destroy(qlock);

     apr_pool_destroy(pchild);
     CloseHandle(exit_event);

MT

Re: [PATCH] WIN9x - Apache has caused an error in LIBAPR.DLL

[Cliff Woolley <cl...@yahoo.com>]

On Sat, 11 Aug 2001, Mladen Turk wrote:

> I think that someone noticed that when shutting down the Apache on WIN9x
> platform you get the exclamation error box stating : "Apache has caused an
> error in LIBAPR.DLL ...." ?

I'm amazed that you got Apache to work even that well on Win9x.  I was
under the impression that it was totally fubar at the moment.  <shrug>

> The error is in locks/win32/locks.c lock_cleanup function that gets the NULL
> as a function parameter. I wasn't able to track the source of the call that
> send the NULL value to apr_lock_destroy but here is the patch that checks if
> the function value is NULL and returns not APR_SUCCESS in such a case

-1.  APR does not typically check parameter correctness.  We leave it up
to the caller to give us a parameter that's valid on the assumption that
if they can't manage to do that then they might not check to see if we
gave them an error return code either.  Besides, if they pass in NULL,
it's easier to debug a SEGV than a return value that gets either ignored
or propagated to some time in the future when it's likely harder to figure
out exactly what happened.

Thanks for looking into this, but we need to keep looking for the source
of the NULL parameter rather than bandaiding it.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA