With Vistors, you're in complete control of the order of visiting child nodes (even to the point of deciding not to visit child nodes). Listeners take care of node navigation for you and you can decide which node to listen in on (either upon enter or exit, as the listener code navigates the tree for you. This make listeners simpler to use if you only interested in doing something on selected nodes (or even if you just don't want the responsibility of navigating the tree. Visitors are much more flexible, but you accept responsibility for how to navigate the parse tree..
The behavior you describe is certainly not my experience with visitors. The base class will generally provide default methods for each node type that do nothing beyond just delegating that their children accept the visitor in order, but ,in your visitor, you override that method, you decide how you want to navigate that node. If you have overridden the visitor for the top node then you decide how, and in what order to visit the children (and each of those children makes a similar decision about which (and in what order) to visit it's children. If you override the method, you control the navigation.
The only way I can imagine the deepest leaf node being "executed" first would be if you were using a listener and only overriding the exit* methods. Then you'd get control as the tree navigation unwinds back to the top.
Try overriding your top level node visitor. It'll be called before any of the children are visited. In fact, the children won't be visited at all if you don't explicitly make a call for them to accept the visitor.