Hi, working with the C# 4.0 version, i have read the issue you had with AccessViolationException on version 9.4.0
i have also tried to work with 9.4.1 version, discuss here: link text
but the bug always returned after the SSH was connected with clients and then i have called StopAllTunnels(1) more then once or if i call BeginAccepting and then after clients are connected StopAllTunnels(1) (more then once)
the Error received is:
Any help will be appreciated.
Please test using this new build:
The call to StopAllTunnels shouldn't crash this time. Instead, it should return false indicating a failed status, and the LastErrorText should end abruptly with the message ("Attempted to read or write protected memory. This is often an indication that other memory is corrupt.".
This is assuming the crash is not already fixed in this new build. If the "crash" occurs with this new build, meaning that StopAllTunnels returns false and the LastErrorText indicates the exception was caught, then please post the contents of the LastErrorText here.
PS> In v9.4.1, all Chilkat methods across all classes will protect the internal calls to the "Cls" implementation such that the LastErrorText will contain the exception message and the method will return a failed status.
answered Jan 27 '13 at 10:32
Thanks its seem to clear this issue, but can i use this version in production/when next version release ?
also, if i receive false when calling to StopAllTunnels, what can i do to really stop the tunnels and provide a way to reopen them when need ?
answered Jan 30 '13 at 04:14
The next version (v9.4.1) is expected to be released in one or two months.
The argument to StopAllTunnels(maxWaitMs) is a max wait time. StopAllTunnels sets a flag that the background process will see, causing it to shutdown each of it's existing tunnels and then exit. If the background process has not responded within the time limit as indicated by maxWaitMs, then the tunnels are forcibly closed from the foreground process and the method returns false. In both cases, the tunnels are closed. The false return only indicates that the background thread did not respond fast enough, and the foreground thread took it upon itself to close the tunnels (using critical sections to synchronize access to shared resources).
answered Jan 30 '13 at 07:43