On Wed, Aug 11, 2010 at 04:24:35AM +0800, Holger Hans Peter Freyther wrote:
Hi all, I was debugging a crash with the VTY and I am not fully understanding it but I can easily reproduce it. The problem is triggered with the new VTY OML code and here is what I know.
thanks for pointing this out.
1.) we move from ENABLE_NODE to the OML node. and allocate memory 2.) when exiting the node we will free the data at vty->index.. and set the pointer to NULL.
yes, that's what it's supposed to do.
But I can easily produce a double free issue and this seems to be due.
strange...
cmd_execute_command: 1.) saves the vty->index to oindex and vty->node to onode 2.) tries calling vty_go_parent or such... 3.) tries more stuff... 4.) as stuff failed resets vty->index to oindex...
ah, ok. I didn't realize that try/revert nature of the vty command execution when coming up with the application-specific go_parent() callback function.
so the next exit command will do a double free... and the funny part is that the code has one assumption everything > CONFIG_NODE is considered to be config as well.
Yes, this is indeed true. I didn't really see a clean way to solve this while generalizing the vty code into libosmovty.
This means that we should have two enum values in libosmovty, one for Last_Enable, one for Last_Config and have enough space between them.
that sound useful. Or we do something like |= some high bit to indicate it is a sub-node of enable or config.
And the other part... maybe vty_go_parent should return CMD_SUCCESS?
I don't really see anybody who uses the result of vty_go_parent(), all the callers seem to discard the return value. However, it doesn't seem right that vty_go_parent does not pass on the retunr value of the host.app_info->go_parent_cb() function.