[ 
https://issues.apache.org/jira/browse/DAEMON-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850597#comment-16850597
 ] 

lode leroy commented on DAEMON-402:
-----------------------------------

I have a service running in java mode (with openjdk8) and when the java code is 
updated it is stopped (net stop ...; update ; net start ...), then we see that 
the process prunsrv frequently crashes. (The java process has a jni dll in use, 
so it needs to be stopped before it's possible to update the dependencies of 
that dll after the nightly build)

There are actually multiple services using the same prunsrv.exe binary and the 
underlying java process is somewhat slow to shut down. This runs on multiple 
test servers, and we see the crashes on several. I also have the problem if I 
run "net start ...; net stop ..." in a loop - with minidumps enabled, I see 
about 1 crash in 5)

On my machine I see no more crashes at all (hundreds of stop/start cycles), nor 
on the test machines that have this fix included.

I think the root cause is that the WM_CLOSE message is sent multiple times.

I would like to see this fix included in 1.1.1 so we can run the official 
prunsrv binary instead of a patched-and-self-compiled one.

 

 

 

> frequent crash in prunsrv
> -------------------------
>
>                 Key: DAEMON-402
>                 URL: https://issues.apache.org/jira/browse/DAEMON-402
>             Project: Commons Daemon
>          Issue Type: Bug
>          Components: Procrun
>    Affects Versions: 1.1.0
>         Environment: windows 10
>            Reporter: lode leroy
>            Priority: Critical
>              Labels: easyfix, patch, windows
>             Fix For: 1.1.1
>
>         Attachments: fix-crash-on-repeated_wmclose.diff
>
>
> I see frequent crashes in prunsrv.exe on Windows 10.
> I have the impression that the WM_CLOSE windows message is sent multiple 
> times - and the code does not expect that, resulting in an attempt to free 
> memory that was already freed.
> Here is a stack trace from a minidump:
>      ntdll.dll!00007ff903af6e1e()    Unknown
>      AcLayers.dll!00007ff87cd77a56()    Unknown
>      prunsrv.exe!HeapFREE(void * hHeap, unsigned long dwFlags, void * lpMem) 
> Line 71    C
>      prunsrv.exe!__apxPoolFreeCore(void * lpMem) Line 133    C
>      prunsrv.exe!apxFree(void * lpMem) Line 402    C
>      prunsrv.exe!__apxProcessCallback(stAPXHANDLE * hObject, unsigned int 
> uMsg, unsigned __int64 wParam, __int64 lParam) Line 396    C
>      prunsrv.exe!apxCloseHandle(stAPXHANDLE * hObject) Line 498    C
>      prunsrv.exe!__apxPoolCallback(stAPXHANDLE * hObject, unsigned int uMsg, 
> unsigned __int64 wParam, __int64 lParam) Line 190    C
>      prunsrv.exe!__apxPoolCallback(stAPXHANDLE * hObject, unsigned int uMsg, 
> unsigned __int64 wParam, __int64 lParam) Line 184    C
>      prunsrv.exe!apxCloseHandle(stAPXHANDLE * hObject) Line 498    C
>      prunsrv.exe!apxHandleManagerDestroy(...) Line 291    C
>      prunsrv.exe!main(int argc, char * * argv) Line 1830    C



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to