ConnectServerInfo weirdness

Hi,

I’m having some problems with ConnectServerInfo.

Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.

So after the name_open, the lib is calling ConnectServerInfo to get the
pid of the server, and if it’s equal to getpid(), I just return.

The problem is that ConnectServerInfo behaves in an unpredictable way:

  • sometimes it returns -1 (error code)
  • sometimes it returns my connection id, but without setting the info
    structure… undocumented and dangerous behaviour
  • sometimes all is fine.

Adding inactive code and recompiling is enough to change the behaviour, so
it sounds like a bug to me.

When calling the lib from another process, all seems fine though.

So my questions:

  • anybody seen that already?
  • should ConnectServerInfo() be working with a connection from one process
    to itself?
  • if yes how to avoid the bug in the function…
  • if no, any suggestion on how to identify whether the process under a
    specific name is yourself?

Thanks in advance,
Philippe

\

Philippe Berger
Software Developer
MineStar Solutions / Aquila Mining Systems Ltd.

BP <pberger@invalid.net> wrote:

Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.

I didn’t think it was possible for a process to open a connection to
itself in the first place (unless it sets _RESMGR_FLAG_SELF on the
pathname, which name_attach() does not appear to be doing) … ?!?
This is because you could then deadlock by sending a message to
yourself if this was allowed as the default. So, are you sure that
ConnectServerInfo() is not failing (are you checking for the return
value to be the coid that you are looking up, not necessarily -1)?

John Garvey <jgarvey@qnx.com> wrote:

BP <> pberger@invalid.net> > wrote:
Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.

I didn’t think it was possible for a process to open a connection to
itself in the first place (unless it sets _RESMGR_FLAG_SELF on the
pathname, which name_attach() does not appear to be doing) … ?!?

Actually, it is pretty common to create a connection to yourself
with ConnectAttach() – no flags needed. Similarly, name_open()
doesn’t generate an _IO_OPEN message to the channel owner, so
there should be no problems with deadlock.

This is because you could then deadlock by sending a message to
yourself if this was allowed as the default.

chid = ChannelCreate()
self_coid = ConnectAttach( …, chid, … _NTO_SIDE_CHANNEL, … );
SIGEV_PULSE_INIT( &ev, … self_coid, …);
time_create(… &ev, … );

Very common.

So, are you sure that
ConnectServerInfo() is not failing (are you checking for the return
value to be the coid that you are looking up, not necessarily -1)?

Still worth checking.

Can you post a snippet of the code doing this and failing?

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote off-topic:

John Garvey <> jgarvey@qnx.com> > wrote:
BP <> pberger@invalid.net> > wrote:
Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.
I didn’t think it was possible for a process to open a connection to
itself in the first place (unless it sets _RESMGR_FLAG_SELF on the
pathname, which name_attach() does not appear to be doing) … ?!?
Actually, it is pretty common to create a connection to yourself
with ConnectAttach() – no flags needed.

I thought we were talking about name_attach() and name_open(). So,
in that context, I mean pathname resolution does not occur to yourself.

chid = ChannelCreate()
self_coid = ConnectAttach( …, chid, … _NTO_SIDE_CHANNEL, … );
SIGEV_PULSE_INIT( &ev, … self_coid, …);
time_create(… &ev, … );
Very common.

But not in the name_attach() or name_open() code.

On Thu, 30 Oct 2003 19:07:25 +0000, John Garvey wrote:

BP <> pberger@invalid.net> > wrote:
Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.

I didn’t think it was possible for a process to open a connection to
itself in the first place (unless it sets _RESMGR_FLAG_SELF on the
pathname, which name_attach() does not appear to be doing) … ?!?

It is possible and working fine: I can create and use the connection
without a problem or warning (and of course lock the process, as
expected).

Actually I fixed my problem: ConnectServerInfo() takes a _server_info*, it
turns out I was just creating a pointer, instead of creating a struct and
giving its address… hence a memory allocation problem and the
unpredictable behaviour.
/me hides under the desk in shame…

Now all works fine, my library detects that the server is connecting to
itself and returns before locking.

Thanks for the replies,
Philippe


Philippe Berger
Software Developer
MineStar Solutions / Aquila Mining Systems Ltd.

BP <pberger@invalid.net> wrote:

On Thu, 30 Oct 2003 19:07:25 +0000, John Garvey wrote:
Specifically, I’ve got a library which connects to a server (through
name_open), and I wanted to make the library safe by ensuring the server
wouldn’t connect to itself.
I didn’t think it was possible for a process to open a connection to
itself in the first place (unless it sets _RESMGR_FLAG_SELF on the
It is possible and working fine: I can create and use the connection
without a problem or warning (and of course lock the process, as

Ah, OK; now I see the special-case role of _FTYPE_NAME in pathname
resolution within procnto. So, you can name_open() yourself but not
open() yourself (unless you specifically allowed it via SELF flag).

Actually I fixed my problem: ConnectServerInfo() takes a _server_info*

Great!