Forum OpenACS Development: Re: Naviserver on Windows - "select failed" when using ns_sockselect

Thanks to your advice Gustaf and Maurizio, I was able to debug the problem, and trace it to the -originator value being to smtp::sendmessage. Maurizio, you were correct that I was on the wrong track trying to debug ns_sendmail. So I have mails working now successfully, which is great news.

Having said that, I have been seeing some very strange stuff in the error log, binary characters and other strange chunks of data. For example, when I was logging the smtp commands, the following was logged:

Notice: send cmd: smtp::sendmessage ::mime::1 -originator bounce-1117-9C0499595A910E12E497926278F46FE356E9CE07-371@localhost -header {From} -header {Reply-To} -he meters.parameter_id
and apm_parameters.parameter_name =

There are 2 strange things there: 1) the 3rd -header is corrupted and contains binary characters (which I couldn't copy from the log), and 2) the SQL clause somehow appearing on the end of the smtp command!

I'm happy to help looking in that if you think it's an issue.

thanks again!

Dear Brian,
at the moment this is my main concern, this sort of erratic behaviour...

In these days I have "normalized" the treatment of socket things like EINTR, EWOULDBLOCK, EINPROGRESS.
Gustaf did some of it, but some other stuff was missing.
Basically for new compilers, instead of the above values we need to use WSAEINTR, WSAEWOULDBOCK, and so on...
This change alone made lot of the crap in the log disappear.

But there's still a long way to go.

The strategy I'm following at the moment is, ehm, rather awful... Whenever I think I have identified something, some area that in the code could be the source of the problem, I check it against how it was done in AOLserver, hoping to find some differences....

For instance, the unbalanced bracket thing, does not show up till the sweep-procs background processing start...

There's is something touching with threading and memory, but haven't track it yet. And I am doing this in my spare time...

Dear Brian, the problem with the broken entries in the log file should be fixed by [1]. see also [2] -g


Thanks Gustaf,

will try to test as soon as possible.