crash in ofstack

[Tsunamis]

Hi,

I'm currently working on SR and when navigating between nodes (using the gotoNode function), I fall upon an error for deleting an already deleted pointer...

So maybe it has nothing to do with the ofstack part but here is the problem... the program crashes down after passing two times in this function... first time, it is ok, and second, the delObj gets a valid pointer, the head gets a pointer Null from the header->next, and fatally, the delObj, passes to the Null as well and causes a crash.
I understand that the pointer affectation makes happening to delObj all what is happening to head, but the checking before doesn't seem to handle that...
Is it a problem in ofstack or in the stack content???
Do I have to correct the dcmtk ofstack and recompile?

Code: Select all

    /** removes top element from stack.
     *  precondition: stack not empty.
     */
    void base_pop()
    {
      assert(head!=NULL);
      OFStackLinkBase * delObj = head;
      head = head->next;
      delete delObj;  //here deletes null pointer when head->next is null
      stackSize--;
    }

________
Honda H engine
________
ultimate fighter

[Tsunamis]

Shouldn't that be something like

Code: Select all

    /** removes top element from stack.
     *  precondition: stack not empty.
     */
    void base_pop()
    {
      assert(head!=NULL);
      OFStackLinkBase * nextObj= head->next;
      delete head;
      head = nextObj;
      stackSize--;
    }

________
volcano classic vaporizer
________
wiki vaporizer

[Tsunamis]

Oh OK finally I understood... well for sure it should go ok, but I still have this problem... and I do NOT delete any object in the stack...
Damn what could cause this stack to go wrong....
________
Honda J-VX
________
Ford LTD history

[Jörg Riesmeier]

Do you have a small piece of code (main function) that demonstrates this issue?

[Tsunamis]

OK here is the global thing :
I use a QT listview to store a graphic visualization of the SR Tree.
To test my application, i use test SR your dcmtk sample SR.

The problem appears when I try to add some node to the basic tree. I call the

Code: Select all

[u]mySRDoc->gotoNode(refItem->text(2).toInt());[/u]
newNodeID = mySRDoc->addContentItem  (myRType, DSRTypes::E_ValueType::VT_Text, DSRTypes::E_AddMode::AM_belowCurrent ) ;
		if (newNodeID == 0) debugFind = false;
		//insert into listView struct
		newItem = new QListViewItem(refItem, mySRDoc->getRelationShipName(myRType), mySRDoc->getValName(DSRTypes::E_ValueType::VT_Text), QString::number(newNodeID));

underlined is the line code that usually crashes the program.
the refitem is an item from my listView. it returns somethins non zero in all tests (integer like 3 or 4). When filling in the refItem, the functions called (XXXName) are function encapsulating calls to valueToReadableName and relationshipToReadableName. QString::number generates a string from a number.

This happens correctly and some node are added to the list and the SR tree. Never in my tests the nodeID returned was set to zero. (debugFind enver gets to false).

The problem is posed when I call gotoNode :

Code: Select all

	mySRDoc->gotoNode(nodeID);

MySRDoc is a class that encapsulate calls to DSRDocument.
gotonode calls DSRDocument.getTree().gotonode(size_t nodeID)

I remarked that the problem happens nearly systematically when creating nodes below an original node that hadn't any children before.
If the node had children the problem happens but generally after three or four node creations.
The hard point is that in both cases, sometimes it works fine.

when debugging, i go into gotonode, it comes into several functions until getting to the while cleaniong the ofstack. When checking the pointers, i see that delObj has a good and valid pointer reference (not 0x000000) but delete delObj crashes.
The function gotoNode (inherited from DSRTreeNodeCursor) calls gotoRoot which empties the stack.

I do not change anything in the stack directly and I don't delete any pointer.

I hope it will be enough to help you trace the problem
________
Honda Airwave specifications
________
medical marijuana card

[Jörg Riesmeier]

I'm sorry but I would prefer a small piece of code which reproduces the problem and which can be compiled with DCMTK only. See mkreport to get an impression of what I mean.

[Tsunamis]

Well... I tried to reproduce that using the standard calls, and it seems to work, when i pass through my interface, it crashes... so I must assume my interface implies the bug... the problem is, if I make the same thing automatically with a sequence of calls to addContentItem and gotonode it works, and if i make the same calls but delayed by clicking the interface, it crashes...
Well, i debugged all that and placed a debug console line each time the dsrdoc is called and that are the same calls, with the same sequence and same params... I think I may miss an error... I'll construct the whole tree at end I think since the sequence is ok...

just for you to know a sequence that i can make an error when chaining calls (on sr report16.dcm):
gotonode(0)
gotonode(0)
gotonode(1)
gotonode(1)
AddNode(PName, HasAcqContext, below)
gotonode(9)
gotonode(2)
gotonode(2)
AddNode(PName, HasProperties, below)
gotonode(2)
CRASH

but it doesn't crash when executing directly all these. I tried 5 times to make the same in my interface without success...

Sorry for disturbance, the error probably come from outside dcmtk
________
ZR1200A
________
iolite review