Matching problem?

Matching problem?

[Kiran Pamnany]

...
begin try
  syscall (fun () -> Unix.connect s ...
  ...
with
  Unix.Unix_error(UNIX.EINPROGRESS,_,_) -> ...
  | Unix.Unix_error(e,_,_) -> ...
  | err -> prerr_endline (Printexc.to_string err)
done;
...

The output for this is:

Unix.Unix_error(38, "connect", "")

How is this possible?

For background: this code is from the connect_server
method in the http_client package from ocamlnet's
netclient (I added the last with pattern).

I'm trying to write an XML-RPC client, using the
XML-RPC package. One simple test client works
perfectly. The actual client is giving me this
behavior.

I put in a try block around the place in the XML-RPC
package where http_client is called. The with clause
there catches Unix.Unix_error(e,_,_). But, this
exception should never leave this connect_server
method because there's a pattern which matches it.
Even stranger is the output when I added the final
with pattern above.

What could be going on?

Thanks in advance for any tips.


K


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Caml-list] Matching problem?

[Andrej Bauer]

Kiran Pamnany wrote:
> ...
> begin try
>   syscall (fun () -> Unix.connect s ...
>   ...
> with
>   Unix.Unix_error(UNIX.EINPROGRESS,_,_) -> ...
>   | Unix.Unix_error(e,_,_) -> ...
>   | err -> prerr_endline (Printexc.to_string err)
> done;
> ...
> 
> The output for this is:
> 
> Unix.Unix_error(38, "connect", "")
> 
> How is this possible?

I am just guessing, but the exception handler for the second case calls 
Unix.close on line 963, which could raise a further exception that would 
not get caught. Also some of the Unix.xxx calls before the begin..try 
block could raise an exception. The odd thing is you're getting 
Unix_error(_, "connect", _), i.e., as if the actual call to Unix.connect 
causes it. By the way, isn't error 38 "function not supported"? What 
does that tell us?

Andrej

Re: [Caml-list] Matching problem?

[Kiran Pamnany]

Thanks for the response.

> > ...
> > begin try
> >   syscall (fun () -> Unix.connect s ...
> >   ...
> > with
> >   Unix.Unix_error(UNIX.EINPROGRESS,_,_) -> ...
> >   | Unix.Unix_error(e,_,_) -> ...
> >   | err -> prerr_endline (Printexc.to_string err)
> > done;
> > ...
> >
> > The output for this is:
> >
> > Unix.Unix_error(38, "connect", "")
> >
> > How is this possible?
>
> I am just guessing, but the exception handler for the second case calls
> Unix.close on line 963, which could raise a further exception that would
> not get caught. Also some of the Unix.xxx calls before the begin..try
> block could raise an exception. The odd thing is you're getting
> Unix_error(_, "connect", _), i.e., as if the actual call to Unix.connect
> causes it. By the way, isn't error 38 "function not supported"? What
> does that tell us?
>

It is definitely the connect(). I've put calls to
prerr_endline() calls in each with case.

38 is EINPROGRESS. I've verified this in a couple
of ways. First, the simple client (that works)
causes the first with case to be entered (because
the socket is set to non-blocking, this is the
usual case). The print there outputs 38. Second,
I put a try-with block in xmlRPCClient.ml, around
the call which causes connect_server() to be
invoked. The with case there is written EINPROGRESS
and it catches this exception.

I'm at a loss. I would suspect the code generated
to match the with patterns but this is in a library
and it works with one client and not another.

Any chance this is because of namespace conflict?
What else could cause this behavior?


K


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Caml-list] Matching problem?

[malc]

On Tue, 14 Aug 2007, Kiran Pamnany wrote:

> Thanks for the response.
>
>>> ...
>>> begin try
>>>   syscall (fun () -> Unix.connect s ...
>>>   ...
>>> with
>>>   Unix.Unix_error(UNIX.EINPROGRESS,_,_) -> ...
>>>   | Unix.Unix_error(e,_,_) -> ...
>>>   | err -> prerr_endline (Printexc.to_string err)
>>> done;
>>> ...
>>>
>>> The output for this is:
>>>
>>> Unix.Unix_error(38, "connect", "")
>>>
>>> How is this possible?
>>
>> I am just guessing, but the exception handler for the second case calls
>> Unix.close on line 963, which could raise a further exception that would
>> not get caught. Also some of the Unix.xxx calls before the begin..try
>> block could raise an exception. The odd thing is you're getting
>> Unix_error(_, "connect", _), i.e., as if the actual call to Unix.connect
>> causes it. By the way, isn't error 38 "function not supported"? What
>> does that tell us?
>>

~$ grep 38 /usr/include/asm-generic/errno.h
#define ENOSYS          38      /* Function not implemented */

# print_int (Obj.magic Unix.EINPROGRESS);;
38- : unit = ()

I.e. tagged vs plain integers

>
> It is definitely the connect(). I've put calls to
> prerr_endline() calls in each with case.

[..snip..]

>
> Any chance this is because of namespace conflict?
> What else could cause this behavior?

The first thing that caught my eye yesterday when i read the original
posting was this:

Unix.Unix_error(UNIX.EINPROGRESS,_,_)

(notice the incorrect capitalisation of module name), but i assumed
this to be a c&p mistake (which it probably is).

-- 
vale

Re: [Caml-list] Matching problem?

[Kiran Pamnany]

> > Any chance this is because of namespace conflict?
> > What else could cause this behavior?
>
> The first thing that caught my eye yesterday when i read the original
> posting was this:
>
> Unix.Unix_error(UNIX.EINPROGRESS,_,_)
>
> (notice the incorrect capitalisation of module name), but i assumed
> this to be a c&p mistake (which it probably is).
>

Typo, yes. It is correct (Unix.EINPROGRESS) in the
code.

Just to repeat the weird part--this code works
with one client. The exact same code breaks with
a different client. I'd guess that ocamlnet is
pretty stable. The problem is unlikely to be in
the xmlrpc package either, since that code is
also the same across the two clients. But what
could be causing this in the broken client?


K


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.