Tree Control General Protection Fault

[kevin.key]

Problem:

Inserting too many Items into a tree control eventually causes a General Protection Fault. I maintain a max tree size by removing an item when I add an item if I'm at the max size. When I set the max size to 500 sometimes I get the General Protection Fault sometimes I don't. When I set the max tree size to greater than 1000 I get the General Fault Protection error relatively quickly. The error always occurs at the InsertItem function call.

Background:

I've been working on a CAN bus monitor, and I've been running into some problems. The basic architecture of the program consists of the main thread for the UI events, a thread for TCP communication and a thread for displaying the bus traffic. 

The TCP communication is with an RT target. The RT target is streaming the CAN bus traffic back to the cvi application running on my computer. The thread handling the TCP communication is just queueing the frames in a thread safe queue.

The second thread is servicing the queue and displaying the frames based on the various states the bus monitor could be in. The two main modes are fixed and chronological. In fixed you just replace the tree item with the same frame ID or add a new one if it doesn't exist. In chronological you just add the frame to the end.

Also:

When in chronological mode I see a CPU usage of about 60% and in fixed mode about 30%.

Could the General Protection Fault (although it always happens at the InsertItem call) be caused by something else that is going on in the application?

Any help will be appreciated,

Thanks,

Kevin

[nickb]

Hey Kevin -

I've not been able to reproduce what you're seeing.  What version of CVI are you using?  Better yet - what is the version number of your run time engine (c:\windows\system32\cvirte.dll)?

If you're not using the CVI 2010 RTE (10.0.0.xxx), you could try updating to version 2010 to see if that resolves the issue.  We've recently fixed a handful of issues related to our UI library and multithreading.

If you run the program outside of the CVI debugger, it should crash like any other windows program.  If you're using CVI 9.0.1 or later, can you generate a crash dump and post it to our ftp site as described here?

Thanks -

NickB

National Instruments

[kevin.key]

The cvirte.dll version is 10.0.0.360.

I will get a crash dump for you.

[kevin.key]

I added gtx_bus.zip to the ftp location.

Thanks,

Kevin

[nickb]

Thanks Kevin -

We've found the root cause of the crash.  I've created a bug report with ID 294725 for further investigation.  I'll post back as soon as we have more information.

NickB

National Instruments

[kevin.key]

Alright, thanks for the quick response.

Kevin

[nickb]

Hey Kevin -

We haven't been able to reproduce the crash here yet - it appears to be pretty heavily dependent on memory alignment - but I think we may have a workaround you can try.  It's a little bizarre, but we'd like to know if it resolves the issue for you.

The general idea is to make sure the tree is in edit mode before you add or remove items.  To do this, you need to make sure the tree can be programmatically placed into edit mode.  This requires calling the following function:

SetCtrlAttribute (panelHandle, PANEL_TREE, ATTR_TREE_EDITABLE_CELLS, 1);

If you don't mind the effects of this function, you can call it once, otherwise you will need to toggle it's value before and after every tree item add and remove.  Once the tree can be programmatically placed into edit mode, you should call the following function before adding or removing items:

SetTreeCellAttribute (panelHandle, PANEL_TREE, 0, 0, ATTR_TREE_RUN_STATE, VAL_EDIT_STATE);

This places tree item 0 in edit mode.  Again, if you don't want the tree item to remain in edit mode, you will need to toggle it's value before and after every call to add and remove items.

If you can give this a try, we'd really appreciate knowing the results of this test.

Thanks -

NickB

National Instruments

[kevin.key]

When placing an item in the edit state, should I place the item that is being removed in the edit state? What if I'm adding an item which state do I place in edit mode?

Setting the ATTR_TREE_EDITABLE_CELLS to 1 at the beginning of my program and 0 at the end doesn't prevent the General Protection Fault.

I don't want to be able to edit anything anyways. I'd prefer that the tree control was just an indicator, but if you make it an indicator you can't resize the columns.

[nickb]

It actually doesn't matter what cell you set to be in edit mode - simply the act of putting one of them in edit mode ought to be enough to avoid the crash.  I've attached an example that demonstrates the workaround.  The code I've attached disables editing cells by swallowing the EVENT_BEGIN_EDIT_TREE_CELL event.

I know this is not ideal, but it will help us to verify that the issue we've found is indeed the cause of your crash.

Let me know if you have any questions.

NickB
National Instruments

[kevin.key]

It doesn't seem to be preventing the general protection faults. Instead of breaking on the InsertItem call it breaks on this call:

SetCtrlAttribute(MAIN_PANEL, PANEL_TREE_TRACE, ATTR_TREE_EDITABLE_CELLS, 0);