Critical error on stunnel 434 for WinCE/Windows Mobile: no service at all, because of failure in thread creation
Hello Michal, Maybe you remember me, I am the man that refreshed stunnel for winCE up to 4.27 version. Thank you for having included my code to your mainstream at that time. As a win32 regular programmer I always check that my code is as close as possible as that of the main win32 stream for PC. I am writing you today to point out a critical bug that prevent stunnel 4.34 from servicing any service at all . I have fixed that bug and will send you a refresh of all the sources (that needed some after some win32 PC version updates) soon. SO DO NOT DO ANYTHING. the bug is in sthread.c: the wince _beginthread port has been modified (by someone else but me) as this : v434: handle=CreateThread(NULL, stack_size, (LPTHREAD_START_ROUTINE)start_address, arglist, STACK_SIZE_PARAM_IS_A_RESERVATION, &thread_id); the "STACK_SIZE_PARAM_IS_A_RESERVATION" flag is the novelty from 4.27. The problem is that beginthread is being called from gui.c with stacksize=0 SO THAT a stack of 0 size "TRIES to be RESERVED" and then CreateThread FAILS to return a valid handle. That is to say that no thread is created, and thus NO TUNNELING SERVICE at all can be delivered. So stunnel cannot work at all. Solution : the proper call is : handle=CreateThread(NULL, stack_size, (LPTHREAD_START_ROUTINE)start_address, arglist, (stack_size > 0) ? STACK_SIZE_PARAM_IS_A_RESERVATION:0, &thread_id); I repeat and insist : please DO NOT DO anything to the code, as I will send soon a refresh with various other updates (because apart from that critical bug, the code needs other refresh to compile properly), and as I am also working on a refresh of openssl up to 1.0.0a (those gentlemen at openssl never included any wce patch to their mainstream, which is really a pity, but another story). See you soon, Thank you again for all the work you do for the community of people, Pierre
Pierre DELAAGE wrote:
Maybe you remember me, I am the man that refreshed stunnel for winCE up to 4.27 version. Thank you for having included my code to your mainstream at that time.
Thank you. I appreciate your public domain patch sent 10 Jan 2009.
the bug is in sthread.c: the wince _beginthread port has been modified
You're right. I obviously made a mistake here. Thank you. In gui.c: _beginthread(ThreadFunc, 0, NULL); should be: _beginthread(ThreadFunc, DEFAULT_STACK_SIZE, NULL);
I repeat and insist : please DO NOT DO anything to the code, as I will send soon a refresh with various other updates (because apart from that critical bug, the code needs other refresh to compile properly),
I prefer individual patches for separate issues rather than a single, large patch. I also tend to rewrite code anyway rather than simply apply patches. It might be better if you just describe problems instead of sending the code.
and as I am also working on a refresh of openssl up to 1.0.0a (those gentlemen at openssl never included any wce patch to their mainstream, which is really a pity, but another story).
It would be great to have a patch to build OpenSSL with arm-cegcc. 8-) Best regards, Mike
Hello Michal, Your fix and mine are cumulative : it is allowed to specify "0" for stacksize in _beginthread, in which case the spec says that the actual stacksize will default to that of the calling thread. Presently such a 0 will lead CreateThread and _begithread to fail. My patch will lead to have as "default" the /STACK option value of the linker, ie 1MB with wce compiler if /STACK unspecified. It would be uselessly luxuous to modify _beginthread to "really" get the calling thread stack size as default. Then, gui.c, or anyother caller, will be "free" to call _beginthread with 0 as stacksize or not. This is the subject of your patch. Apart from that my soon global patch will only fix "compilation issues", not execution issues. In general, after the 4.27 refresh and the unicode bug last year I will stay focused on unicode/ascii support and compilation issues on WCE, and I will deal with "operational" code only when encountering a bug. My present aim being to offer a port of stunnel for WCE, without touching the core cryptographic code, something I prefer to let to ssl specialists See you soon with my patch, Pierre Le 26/09/2010 19:25, Michal Trojnara a écrit :
Pierre DELAAGE wrote:
Maybe you remember me, I am the man that refreshed stunnel for winCE up to 4.27 version. Thank you for having included my code to your mainstream at that time.
Thank you. I appreciate your public domain patch sent 10 Jan 2009.
the bug is in sthread.c: the wince _beginthread port has been modified
You're right. I obviously made a mistake here. Thank you.
In gui.c: _beginthread(ThreadFunc, 0, NULL); should be: _beginthread(ThreadFunc, DEFAULT_STACK_SIZE, NULL);
I repeat and insist : please DO NOT DO anything to the code, as I will send soon a refresh with various other updates (because apart from that critical bug, the code needs other refresh to compile properly),
I prefer individual patches for separate issues rather than a single, large patch.
I also tend to rewrite code anyway rather than simply apply patches. It might be better if you just describe problems instead of sending the code.
and as I am also working on a refresh of openssl up to 1.0.0a (those gentlemen at openssl never included any wce patch to their mainstream, which is really a pity, but another story).
It would be great to have a patch to build OpenSSL with arm-cegcc. 8-)
Best regards, Mike
_______________________________________________ stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users
Pierre DELAAGE wrote:
My patch will lead to have as "default" the /STACK option value of the linker, ie 1MB with wce compiler if /STACK unspecified.
Such a large virtual memory reserved for each stack thread is a very bad idea on 32-bit CPUs. WCE makes it even worse, since each process is contained (unless some special tricks are used) within a 32MB slot: http://msdn.microsoft.com/en-us/library/aa450572.aspx That's why I recently received a report that stunnel is not able to create more than 32 threads on WCE.
It would be uselessly luxuous to modify _beginthread to "really" get the calling thread stack size as default.
I don't remember stunnel using calling stack size for any purpose...
In general, after the 4.27 refresh and the unicode bug last year I will stay focused on unicode/ascii support and compilation issues on WCE, and I will deal with "operational" code only when encountering a bug.
I'd appreciate some help with testing as I currently don't have an eVC configured. Mike
Le 26/09/2010 21:53, Michal Trojnara a écrit :
Pierre DELAAGE wrote:
My patch will lead to have as "default" the /STACK option value of the linker, ie 1MB with wce compiler if /STACK unspecified.
Such a large virtual memory reserved for each stack thread is a very bad idea on 32-bit CPUs. WCE makes it even worse, since each process is contained (unless some special tricks are used) within a 32MB slot: http://msdn.microsoft.com/en-us/library/aa450572.aspx That's why I recently received a report that stunnel is not able to create more than 32 threads on WCE.
Sure, this is where YOUR patch is entering in action, by explicitely specifying a 65K stack for each thread, at _beginthread calling time. This is what I meant by "cumulative" effect of our both patch. Mine is more related to "proper" functionality of _beginthread. With your permission, I will include your gui.c trick on my next patch, so that we have a complete consistent solution to that problem.
It would be uselessly luxuous to modify _beginthread to "really" get the calling thread stack size as default.
I don't remember stunnel using calling stack size for any purpose... Sure.
In general, after the 4.27 refresh and the unicode bug last year I will stay focused on unicode/ascii support and compilation issues on WCE, and I will deal with "operational" code only when encountering a bug.
I'd appreciate some help with testing as I currently don't have an eVC configured. This is exactly what I basically offer to the project.
Pierre
_______________________________________________ stunnel-users mailing list stunnel-users@mirt.net http://stunnel.mirt.net/mailman/listinfo/stunnel-users
participants (2)
-
Michal Trojnara -
Pierre DELAAGE