I haven't gotten a chance to really scrub DUM for leaks, so you may be encountering something there (provided you are using DUM, correct me if this isn't the case). The fact that it is having trouble even with PEDANTIC_STACK is interesting. This says to me that maybe we're tripping over semantic garbage (transaction garbage; screwy stuff like tid collisions).
If you haven't performed this test under valgrind, please do so. That should clear up any possibility of full-blown leaks. State-bloat is a little trickier to diagnose. (by state-bloat, I mean that we have failed to clean up state that we are no longer using, ie TransactionStates lying around because a response never came back from the TU)
If you run your scenario at DEBUG, you should get a list of all the "leaked"(state-bloat) TransactionStates on shutdown (they look something like "68912734 -> 0xfeedbeef" , the first thing is the tid, the second is the address where this TransactionState lives). If you also keep a _complete_ packet trace, you can search it using the tid (68912734) to figure out which packets caused the leak.
Best regards, Byron Campen Hi, I am using resiprocate-1.1 libraries for my B2B application on RHEL 3.0. I have observed that there is a significant memory leak (about three to four fold increase) when Protos or Sivus is run. This happens even if I compile the stack by setting the PEDANTIC FLAG option. The memory does not decrease even after 30 to 45 minutes of idle time. Has anyone observed this or is it a known thing? Regards, Mayur _______________________________________________ resiprocate-devel mailing list
|