jimwgramling@gmail.com writes:

>> But SYSV shared memory is another story -- shutting down *all*
>> instances of apps using it doesn't clean shared memory.
>>
>
> But that is the whole point of this problem: the server (an Ingres
> database server, fyi) does use shared memory. The client / fe
> software absolutely does not.

How do you know that the client doesn't attach to the Ingres shared
memory segment? Your own code may not use it, but that "client
shared library" that you link against may well do so.

Note that for the server to use shared memory only makes sense if
either
- the server itself is implemented as several (more than one)
communicating processes, or
- its clients *also* use shared memory.

> I ran with MALLOCTYPE=debug and captured a core.

It might help if you posted the actual crash stack trace from dbx.

> The problem persisted in all instances (processes) of the user app
> until I shut down the server.

This is consistent with the server getting into a state where
it provides "unexpected" answer to all the clients.

Whether this is due to a bug in the server (provides "wrong" answer),
or in the clients (which do not anticipate all possible answers),
is hard to tell without more details.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.