LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Program always crashs after a few hour' work

My Labview Program always crashs after a few hour' work. The error report is:

 

 

####
#Date: 2014年7月30日 4:27:27
#OSName: Windows 7 Ultimate
#OSVers: 6.1
#OSBuild: 7600
#AppName:
#Version: 12.0 32-bit
#AppKind: AppLib
#AppModDate: 07/29/2014 20:13 GMT
#LabVIEW Base Address: 0x30000000

 

<DEBUG_OUTPUT>
2014/7/30 8:34:11.006
DAbort 0xF50EFD7B:
c:\builds\penguin\labview\components\mgcore\trunk\12.0\source\MemoryManager.cpp(1104) : DAbort 0xF50EFD7B:
minidump id: 6ebe0400-78d2-41e3-b2fd-858c21e3567b
$Id: //labview/components/mgcore/trunk/12.0/source/MemoryManager.cpp#13 $

</DEBUG_OUTPUT>
0x30076B23 - lvrt <unknown> + 0
0x307D1F90 - lvrt <unknown> + 0
0x30605C66 - lvrt <unknown> + 0
0x6C42A045 - nivissvc <unknown> + 0
0x075A1F00 - nivision <unknown> + 0
0x03B0577A - <unknown> <unknown> + 0
0xE5BA0800 - <unknown> <unknown> + 0

 

 

Who knows what had happened? Thank you for your help.

0 Kudos
Message 1 of 8
(4,216 Views)

You are running out of memory. Are you building arrays continuously? Without seeing your code we can't tell you what to fix. But, the problem is definitely a memory issue.

0 Kudos
Message 2 of 8
(4,212 Views)

Thank you for your reply.

I don't build array continuously. I just build a few queues. I am sorry the program is too large to show it to you. I have read the dump file. It seems like memory overflow. Do you think so? But it seems like there is no chance for memory overflow in Labview. The dump file is as below:

 

 

Microsoft (R) Windows Debugger Version 6.3.9600.17029 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\LabVIEW Data\LVInternalReports\1.0.0.1\51437f73-aab6-4097-b7e1-3fee8a74e4dd\6ebe0400-78d2-41e3-b2fd-858c21e3567b.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response Time (ms) Location
OK C:\Program Files (x86)\Symbols
Symbol search path is: C:\Program Files (x86)\Symbols
Executable search path is:
Windows 7 Version 7600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed Jul 30 08:34:10.000 2014 (UTC + 8:00)
System Uptime: not available
Process Uptime: 0 days 4:06:44.000
................................................................
................................................................
..........................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(dfc.4b8): Unknown exception - code 00000002 (first/second chance not available)
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
*** WARNING: Unable to verify timestamp for kernel32.dll
*** ERROR: Module load completed but symbols could not be loaded for kernel32.dll
eax=13dbec20 ebx=13dbe550 ecx=00000008 edx=00000008 esi=00000003 edi=13dbe570
eip=77b564f4 esp=13dbe500 ebp=13dbe59c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll+0x464f4:
77b564f4 c3 ret

0 Kudos
Message 3 of 8
(4,171 Views)

well its very hard to tell something by only seeing dump file ( or atleast for me)

but as greg said it is almost impossible to tell somthing without seeing the code.

are you using Vision, if yes are you sure you are handling image buffers correctly.

Are there operations like inserting in an  array continiously , what types are data structures.

there are lots more things but all are wild guess only.

0 Kudos
Message 4 of 8
(4,161 Views)

Thank you for your reply.

 

I indeed used vison module. I used four cemeras to collect images. I will check the images handles.

 

Thank you!

0 Kudos
Message 5 of 8
(4,148 Views)

Thank you.

 

You are right. I indeed use Vision. I have upload the functions which most likely cause the crash. When I add the gear test function, it crashs more obviously. Please have a look wether there are some misuse.

 

Thank you very much.

Download All
0 Kudos
Message 6 of 8
(4,133 Views)

no i dont see anything , unless you are destorying the buffers at right time after calling this VI.

i see some insert and delete function but probably they would not cause crash.

you can use desktop execution trace toolkit to get more information.

 I have made some changes to your array algorithm check it

0 Kudos
Message 7 of 8
(4,096 Views)

The new crash report is as blow. It may be caused by the function IMAQ FillHole. How this function crash?

Who knows why? Thank you!

 

 

####
#Date: 2014年8月12日 14:21:51
#OSName: Windows 7 Ultimate
#OSVers: 6.1
#OSBuild: 7600
#AppName:
#Version: 12.0 32-bit
#AppKind: AppLib
#AppModDate: 08/12/2014 06:17 GMT
#LabVIEW Base Address: 0x30000000


<LVExec>
{"a":[
{
"vi": "D\\VISION_SYSTEM\\build\\MyProgram.exe\\IMAQ FillHole",
"ctx": "主应用程序实例",
"type": "subVI"
}
,
{
"vi": "D\\VISION_SYSTEM\\build\\MyProgram.exe\\ccd2表面2二值化.vi",
"ctx": "主应用程序实例",
"type": "subVI"
}
,
{
"vi": "D\\VISION_SYSTEM\\build\MyProgram.exe\\ccd3表面检测2函数.vi",
"ctx": "主应用程序实例",
"type": "subVI"
}
] }
</LVExec>

<DEBUG_OUTPUT>
2014/8/12 16:48:15.894
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash 0x0: Crash caught by NIER
minidump id: 6e35643f-8ff2-49e6-bbde-98bac2ffa48a
ExceptionCode: 0xC0000005$N

</DEBUG_OUTPUT>
0x307277B4 - lvrt <unknown> + 0
0x30727B38 - lvrt <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x77CA5A74 - ntdll <unknown> + 0
0x77C8B3C8 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

0 Kudos
Message 8 of 8
(3,964 Views)