You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bert Huijben <be...@qqmail.nl> on 2011/05/11 15:35:40 UTC
LoadLibrary failures? (Was: RE: MinGW status)
> -----Original Message-----
> From: Jeff Trawick [mailto:trawick@gmail.com]
> Sent: woensdag 13 april 2011 14:54
> To: dev@apr.apache.org
> Subject: Re: MinGW status
>
> Oh, how could I forget :)
>
> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
> droplet that looks like this:
>
> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>
> (My initial web searches for this issue were not successful, but I
> didn't try very hard.)
I see similar droplets with apr-1.4.4 on Windows 7 now using Visual C++.
R:\>type Svn-2010\tests\\subversion\svn\svn.exe.1028
76920000 00000001 00001b80 LoadLibraryA() .\misc\win32\misc.c:172
Any idea how to diagnose?
Bert
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2011 4:21 PM, Jeff Trawick wrote:
>
> Should I have meant to? Apparently Not!! I read the comment and not
> the header file.
:)
> I'll suggest a better fix separately.
Coolio :) I expect it's nothing more than dropping the #include and marking
up with more commentary.
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>>
>>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>>> droplet that looks like this:
>>>>
>>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>
> This affects httpd 2.2.18, released. One per pid each time httpd is launched.
> I am of the mind to remove the offending #include and roll an -R2.msi binary
> package, if nobody much minds. I'd leave the -win32-src packages unmolested
> unless people feel strongly.
Rolling the binary with the patch, leaving the source alone, and
providing a patch separately seems reasonable.
>
> You added this;
>
> https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
>
> which was spawned from;
>
> https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
>
> Did you intend to?
Did I intend to? Yes
/* Declared in include/arch/win32/apr_dbg_win32_handles.h
*/
APR_DECLARE_NONSTD(HANDLE) apr_dbg_log(char* fn, HANDLE ha, char* fl, int ln,
int nh, /* HANDLE hv, char *dsc */...)
Should I have meant to? Apparently Not!! I read the comment and not
the header file.
I'll suggest a better fix separately.
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2011 7:39 PM, Jeff Trawick wrote:
> On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr.
>>
>> https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
>
> BTW, who did that one :)
Bugger :) Why, I have no idea, but it was spawned by someone elses
observations. The questions about taking &(handle) sound very very
strange, as if something is misdeclared. I'll research in a week or
few.
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>>
>>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>>> droplet that looks like this:
>>>>
>>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>
> This affects httpd 2.2.18, released. One per pid each time httpd is launched.
> I am of the mind to remove the offending #include and roll an -R2.msi binary
> package, if nobody much minds. I'd leave the -win32-src packages unmolested
> unless people feel strongly.
>
> You added this;
>
> https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
>
> which was spawned from;
>
> https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
BTW, who did that one :)
> Did you intend to?
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>>
>>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>>> droplet that looks like this:
>>>>
>>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>
> This affects httpd 2.2.18, released. One per pid each time httpd is launched.
> I am of the mind to remove the offending #include and roll an -R2.msi binary
> package, if nobody much minds. I'd leave the -win32-src packages unmolested
> unless people feel strongly.
Rolling the binary with the patch, leaving the source alone, and
providing a patch separately seems reasonable.
>
> You added this;
>
> https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
>
> which was spawned from;
>
> https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
>
> Did you intend to?
Did I intend to? Yes
/* Declared in include/arch/win32/apr_dbg_win32_handles.h
*/
APR_DECLARE_NONSTD(HANDLE) apr_dbg_log(char* fn, HANDLE ha, char* fl, int ln,
int nh, /* HANDLE hv, char *dsc */...)
Should I have meant to? Apparently Not!! I read the comment and not
the header file.
I'll suggest a better fix separately.
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, May 11, 2011 at 4:44 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>>
>>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>>> droplet that looks like this:
>>>>
>>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>
> This affects httpd 2.2.18, released. One per pid each time httpd is launched.
> I am of the mind to remove the offending #include and roll an -R2.msi binary
> package, if nobody much minds. I'd leave the -win32-src packages unmolested
> unless people feel strongly.
>
> You added this;
>
> https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
>
> which was spawned from;
>
> https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
BTW, who did that one :)
> Did you intend to?
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>
>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>> droplet that looks like this:
>>>
>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
This affects httpd 2.2.18, released. One per pid each time httpd is launched.
I am of the mind to remove the offending #include and roll an -R2.msi binary
package, if nobody much minds. I'd leave the -win32-src packages unmolested
unless people feel strongly.
You added this;
https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
which was spawned from;
https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
Did you intend to?
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2011 9:23 AM, Jeff Trawick wrote:
>>
>>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>>> droplet that looks like this:
>>>
>>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
This affects httpd 2.2.18, released. One per pid each time httpd is launched.
I am of the mind to remove the offending #include and roll an -R2.msi binary
package, if nobody much minds. I'd leave the -win32-src packages unmolested
unless people feel strongly.
You added this;
https://svn.apache.org/viewvc/apr/apr/branches/1.4.x/misc/win32/misc.c?r1=1084322&r2=1084323&
which was spawned from;
https://svn.apache.org/viewvc/apr/apr/trunk/misc/win32/misc.c?r1=892177&r2=892176&pathrev=892177
Did you intend to?
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, May 11, 2011 at 9:35 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Jeff Trawick [mailto:trawick@gmail.com]
>> Sent: woensdag 13 april 2011 14:54
>> To: dev@apr.apache.org
>> Subject: Re: MinGW status
>>
>> Oh, how could I forget :)
>>
>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>> droplet that looks like this:
>>
>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>>
>> (My initial web searches for this issue were not successful, but I
>> didn't try very hard.)
>
> I see similar droplets with apr-1.4.4 on Windows 7 now using Visual C++.
>
> R:\>type Svn-2010\tests\\subversion\svn\svn.exe.1028
> 76920000 00000001 00001b80 LoadLibraryA() .\misc\win32\misc.c:172
>
> Any idea how to diagnose?
Happens with Visual C++? Great!
Does it happen with apr 1.4.2 in the same build+runtime environment?
If not, I guess we can diff 1.4.2->1.4.4 and start picking out likely
suspects to try.
Re: LoadLibrary failures? (Was: RE: MinGW status)
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 5/11/2011 8:35 AM, Bert Huijben wrote:
>
>> -----Original Message-----
>> From: Jeff Trawick [mailto:trawick@gmail.com]
>> Sent: woensdag 13 april 2011 14:54
>> To: dev@apr.apache.org
>> Subject: Re: MinGW status
>>
>> Oh, how could I forget :)
>>
>> Running myapp.exe against libapr-2-0.dll can result in a myapp.exe.###
>> droplet that looks like this:
>>
>> 75B30000 00000001 00001774 LoadLibraryA() misc/win32/misc.c:175
>>
>> (My initial web searches for this issue were not successful, but I
>> didn't try very hard.)
>
> I see similar droplets with apr-1.4.4 on Windows 7 now using Visual C++.
>
> R:\>type Svn-2010\tests\\subversion\svn\svn.exe.1028
> 76920000 00000001 00001b80 LoadLibraryA() .\misc\win32\misc.c:172
>
> Any idea how to diagnose?
Someone switched up our OPTIONAL system hooks (al la strace) into hard
wired hooks, and I suspect this was done to 1.4.4 as well. Investigating.