Assertion failure in GCShared in 1.3?

[brian]

Hello Again,

I just made the Ice 1.3 installation, non-optimized, and got this failure when my Ice::Application object destructs.

Assertion failed: num == 1, GCShared.cpp, line 69

I did not make 1.2 non-optimized so I did not get this assertion, but it was core dumping upon exit, so maybe this problem is in 1.2 as well.

Anybody know what I might be doing wrong? I noticed there was a bug fix for 1.3 mentioned in the CHANGES file for interrupts on an Ice::Application, but I am not sending any signals nor interrupting, I just allow the application to run to the end of my run() method.

Any ideas?

Brian

[mes]

Hi Brian,

The quickest way for us to help you is for you to provide a small but complete example that demonstrates the problem, as well as a description of your platform and compiler versions.

Take care,
- Mark

[brian]

I was afraid of that response. Before we take the time to provide an example, I assume that this is not some known issue or that some general explanation cannot be provided given the assertion that we can use to try to fix the problem on our end?

Brian

[mes]

No, it's not a known problem (but it could be an unknown one ).

Can you provide a stack trace?

- Mark

[brian]

Okay Mark, here you go. Attatched is output from dbx running on a Solaris box.

Brian

[mes]

I looked at the stack trace, and it appears that there is a reference-counting problem with a servant. It's difficult for me to be more specific without seeing the code in question. If you'd like, you can email the code to me rather than posting it on the forum.

- Mark

[brian]

Mark,

The code is voluminous and it is not practical at this point to send to you.
What is your gut feeling -- is this a problem on our end or a bug in Ice? When you say a reference counting problem, is there ANYTHING we can try to detect, fix, and workaround the problem?

Thanks,

Brian

[michi]

For now, simply comment out the assertion. That will get you off the hook.

What would help me is if you could send me the state of all threads. I suspect that another thread is also destroying (or has just recently destroyed) something that derives from Ice::Object. Also, if you have this happening reliably (that is, on every run, not just occasionally), I'd really like to see your code because that's probably the only way to work out what is going wrong. If you could put together a test case that shows the failure, this would help enormously.

I'm not sure whether this is due to a bug in your code or in our code but, either way, it would be good to know why this is happening, so we can come up with a way to prevent this problem in future.

Cheers,

Michi.

[brian]

Michi,

After extensive investigation I think I know what I was doing wrong. I was creating a servant, adding it to an adapter, and then explicitly calling the delete function on the servant. When I commented the delete out, the assert went away and I noticed that the destructor of the servant was still being called when Ice::Application exits -- I guess when it calls deactivate on all its adapters. (I did not glom this functionality from the manual.) So I guess the reference count of the servant was being decremented too much.

I've attached the stack trace from where the destructor of our servant, ItsOmsProxyFacade, is called.

Does this all make sense to you?

Brian

[michi]

Originally posted by brian
Michi,

After extensive investigation I think I know what I was doing wrong. I was creating a servant, adding it to an adapter, and then explicitly calling the delete function on the servant.

Right. Never call delete on a servant. It's guaranteed to mess up the reference counts. (The whole point of using reference counts is so you don't have to bother with remembering to call delete.)

When I commented the delete out, the assert went away and I noticed that the destructor of the servant was still being called when Ice::Application exits -- I guess when it calls deactivate on all its adapters. (I did not glom this functionality from the manual.) So I guess the reference count of the servant was being decremented too much.

Right. The relevant explanations are on page 256 of the Ice manual. A general explanation of smart pointers starts on page 176.

Cheers,

Michi.