DAbort 0x26550A7E in transact.cpp

Hello,
I'm still a bit new to labview so bear with me. I've only been working with it about 2 months. Today I was making some minor additions to a HUGE program I made in labview when everything went haywire. This morning I successfully added about 4 nested case structures with sub-VIs to make the minor improvements to the program but then it started to freeze up on me like the RAM was overloaded. I restart the program but it was still lagging. I restarted the PC but no better. LabView then started crashing...
I did file recovery on my program a few times and tried to keep working on it but when attempting to add any more sub-VIs it crashed giving me the following error:
DAbort 0x26550A7E in transact.cpp
Version: 12.0 (32-bit)
It stopped lagging after a few times of restarting the PC so the RAM overload is not the issue anymore. I then tried restarting the program several times and trying to edit it again but each time the program would crash as soon as I added ANY sub-VI to it. I wondered if the VI had been corrupted somehow.
I then restarted the computer then began getting the following DataFinder error during startup:
The DataFinder cannot start due to an internal error. (244): Please wait til the National Instruments PSP Service is running and try starting the DataFinder again, or reboot your computer.
I rebooted several times and kept getting that error 244 and Labview continued to crash when I tried to add any sub-VIs to my program.
I found this thread mentioning this sort of error: http://forums.ni.com/t5/LabVIEW/Error-244-The-DataFinder-cannot-start-due-to-an-internal-error/td-p/...
After following the instructions there I still could not get rid of the error. Ultimately, I just disabled DataFinder from msconfig and then proceeded to manually open DataFinder.exe myself after startup finished each time.
At this point I'm not really sure if the DataFinder startup error 244 and the crashing of Labview when I add sub-VIs to my program are related or not.
I'm running labview 12.0
windows xp
2.4GHz processor
2.5GB RAM

Hello Pflowers99,
I've been researching more information regarding to your issue (DAbort 0x26550A7E at transact.cpp) and I've found that this is a very uncommon LabVIEW issue since 2011 version that is currently being investigated. I would recommend you to first make the test with a simpler VI in order to check that there is no problem with adding that subVI to a more simple main program, also I would suggest you to try alternative ways to add the sub-VI to you Main code. You can drag it from your project, or press control+drag the subVI to the block diagram, or drag it from the desktop just to see how that works. Also you can try to run the program in a computer that have a later version of LabVIEW (like LabVIEW 2013 or 2013 SP1) and try to add the sub-VI un these versions in order to check if this problem was fixed for this later versions.
Best regards,
Daniel Cabezas
Applications Engineering
National Instruments
www.ni.com/support

Similar Messages

DAbort 0x1A7102DF in fpsane.cpp when opening a 2011 vi in a machine with 2012 vs

DAbort 0x1A7102DF in fpsane.cpp
Error message appears when i try to open a vi with LV2012 created in other computer with 2011 version.
Does anyone know how to fix it?.

Does the VI open correctly on the 2011 machine?
Do new VIs work correctly on LV 2012? What about opening shipped examples?
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Error transact.cpp when load LabWindows CVI DLL

Hie,
I'm a "newbie" about LabView, and I would like to call a simple LabWindows CVI DLL from LabView. Then for this
I did also a very simple VI (I think : 2 buttons, the first to call my DLL function and the second to quit
my VI). I define my DLL as indicated by NI, all seems OK. After placing and defining parameters about my
DLL function in the diagram, If I "double clic" on the DLL icon in my diagrram, I obtain :
"Failure Transact.cpp, line 1132 ...blabla...blabla".
Another Time, I obtained a message (when I try to run) about
"not enough memory"
the solution is then to kill LabView Process or shunt Down !!!!!
I've tried my "mini" projet on tow systems and I obtained the same results :
Wind
ows 2000 and Windows NT
LabView 6.0 et Lab Windows CVI 6.0
144 Ram and 256 Ram in the two PC and not another application running during my test :
I think then I should have enough ram to do this !
I did not see my problem
thank a lot in advance for any help
file attachement contain hardcopy of VI
Thierry
Attachments:
Bug_Memory_LabView.doc ‏56 KB

Hie,
Now It's OK !!
After submitting my problem to NI, NI has transmitted to me a simple program :
a VI which simply calls a function in a DLL (which loads an UIR), and their solution runs.
Their solution is the "same" as mine except in mine, I have added calls to "MessagePopup"
just to study how running my program like this (see "// Here ->x" ) :
Extract of my code in my DLL :
int __stdcall DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
int iValue=0;
switch (fdwReason)
case DLL_PROCESS_ATTACH:
"// Here ->1" MessagePopup ("Avertissement", "DLL -> Init Ressources DLL LabWindows");
if (InitCVIRTE (hinstDLL, 0, 0) == 0)
return 0; /* out of memory */
break;
case DLL_PROCESS_DETACH:
"// Here ->2" MessagePopup ("Avertissement", "DLL -> Free Ressources DLL LabWindows");
if (!CVIRTEHasBeenDetached())
CloseCVIRTE ();
break;
The problem is located to the line "// Here ->"
When I drag the icon "Call Librairie function" in the diagram of my VI and I define parameters,
immediately a "link" is established between LabView and the DLL, the __stdcall DllMain is called !
then LabView Environnement failed !, you have then to kill the LabView Process !
By changing the "MessagePopup" functions with tracks (*) in a file, I can "debug" my program and I will
have never this artefacts.
change line // Here ->1 with TraceMsg("DLL -> Init Ressources DLL LabWindows");
change line // Here ->2 with TraceMsg("DLL -> Free Ressources DLL LabWindows");
void TraceMsg(char *szBuffer)
int iValue=0;
int iHandle=0;
iHandle = OpenFile("D:\\Thierry\\Formation LabView-LabWindows\\trace.log",
VAL_WRITE_ONLY, VAL_APPEND, VAL_ASCII);
iValue = WriteLine (iHandle, szBuffer,strlen(szBuffer));
iValue =CloseFile (iHandle);
Thierry

Crash "DAbort 0x37C03D in MemoryManager.cpp" when calling DLL with "Call Library Function Node"

Hi all,
I would like to work with a LabVIEW program that I did not programm by myself.
In this programm an external DLL needs to be called. in the Momente this dll ist called with the "Call Library Dunction Node" LabVIEW crashes with this Error Message:
DAbort 0x37C03D in MemoryManager.cpp
Attached is the entire Log.
The programm runs on the computer of the original programer.
I have never handeled with DLLs or something like that before, so I have absolutely no idea how to rsolve this problem.
Thanks for your help!
Attachments:
lvlog.txt ‏2 KB

A DLL can be compiled by different compilers. By "generic" C DLL, i refer to ANSI C (so no C++, no Borland C or something else).
My question is raised as parameters, esp. arrays and strings, can lead to this behavior when used in the wrong way (including "Calling Convention").
Also, interfacing with the LV memory manager can lead to crashes like this, but this wouldn't be a "generic" DLL as it binds to LV (due to LV API calls).
Without a better knowledge on the DLL and its functions, there is not much we can help you with.
Where does the DLL come from?
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

BUG found while running Matlab Script

Hi there,
I am trying a very simple vi exacmple for learning MathScript. My labview is 2011 and my matlab is 2011b, they both install in the same computer. My OS is windows 7 (64bit). I am trying to writing the following script to the block
t=0:0.01:3;
y=sin(t);
while y will be the output name of the MathScript. I connect this symbol to the a graph and run the program. For the very first time, it call out the matlab platform and run the program directly and the result was shown in the graph. However, whenever I want to modify the script and trying to save the vi, it reports some error and the program get terminated "DAbort 0x1A7102DF in fpsane.cpp". It is so weird. If I open the closed VI again, it can run without any problem for the first modificaiton, but the problem comes again if I modify the script again after the first run.

Sorry, I currently don't have matlab installed, so I cannot test your VI containing the matlab script.
If I copy the text of your matlab script to a MathScript node instead, everything works just fine.
It is possible that the problem is within matlab and not a LabVIEW problem. I cannot tell.
MathScript is a LabVIEW toolkit that can run scripts with a matlab like syntax. You need to purchase it seperately (windows), but you can also download an evalution copy to try for free. The version for Mac and linux seems to be free but I have note tried. Are you a student? The LabVIEW student editions also include MathScript.
LabVIEW Champion . Do more with less code and in less time .

LabVIEW Class crash - ntdll.dll access violation

Hi,
When I close my LV11SP1f2 I always get a warning.
It didn't bother me until a vi I wrote that uses a class with nothing out of the ordinary started crashing my LV.
The crash says that: "DAbort 0x37C03D in MemoryManager.cpp"
I sent the log files to the local support and they saw that the common issue between my logs is an access violation in ntdll.dll.
Any operation that uses the property nodes of that crazy class fails, sometimes with a crash and sometimes with a error that sends me to a bundle by name in the autocreated property node.
I rewrote the project with the class and there is no error.
Sending the crashing project to another computer gave no error.
Before I go on and investigate windbg to search for a conflicting app and finally formatting my entire computer could some1 help? Please...
I attached several logs for example.
Thanks in advance,
GoofyWires.
Attachments:
92c82e7b-fa2a-43af-b2be-a6650c031681.zip ‏2485 KB
daa462b5-9395-4e3f-8894-05a3bdb3d159.zip ‏65 KB
ea2c40ef-056d-41ed-a4c5-9cf4bc6666fc.zip ‏494 KB

I did a clean format and reinstalled LabVIEW 11.0.1f2 without adding many of the add-ons from VIPM and without installing the rest of my shortwave, yet, the crash is still here!
I was able to reproduce it on my pc:
1. I have a class that contains two children of another class which each contain another class with a class inside it.
2. I accessed the classed through property nodes.
3. I then went on and deleted a private data from the first class control, deleted its property nodes and added a new private data to that class control and added the property nodes for it.
4. I updated the vi that used the classes to stop using the deprecated property node and start working with the new one.
5. I did a "save all" and run the vi. All OK!
6. I closed LabVIEW and reopened the project and run the vi which is not broken! LabVIEW crashes!!!
I guess the complexity of the class is not the issue and it can be reproduced in a much simpler way.
Yet, since I bet the scenario caused you to raise an eye brow I'll give an example as an analogy:
File Handler class contains ASCII Read class and ASCII Write class which inherit from class ASCII.
Class ASCII parent contains class Headers while class Header contains class Data.
Thus, class ASCII Handler will use class ASCII Read/Write to give a high level simple interface while during the read/write the inner ASCII Read, for example, will add to the Header class in it the read data which will in turn be added to the array in the private data of class Data.
I'll try and reproduce it on a different pc and send the local NI support the code and way to reproduce.
I see two possibilities:
1. Something is wrong with my new Dell PC.
2. LabVIEW doesn't handle and propagate correctly changes in a class to all the vis that use it. Maybe changing the array size in a class overrides some memory since the class can't change its size.
Please let me know if this rings a bell.
Update: I coundn't reproduce the crash on my pc with a simpler case. There is something missing...
I'll try to replroduce with the complex class on a different pc and if it crashes I'll simply send my original code.

Dead lock handling

Hi
I am running a little test that runs two threads that update the same table. Each thread tries to update several documents in the within a single transaction. The update is done by retrieving the document, modifying it, adding the updated document and deleting the existing document.
I have enable dead lock detection and when a dead lock exception is thrown I abort the current transaction.
However after a few iteration, deleteDocument causes a core dump and DBXML prints to stderr : "Previous deadlock return not resolved".
Is there anything else to resolve when a dead lock occurs other than abort the transaction?
This is the relevant stack trace:
#0 0x00421780 in Dbc::get () from /u/yoava/dbxml-2.2.13/install/lib/libdb_cxx-4.3.so
(gdb) where
#0 0x00421780 in Dbc::get () from /u/yoava/dbxml-2.2.13/install/lib/libdb_cxx-4.3.so
#1 0x00934289 in DbXml::SyntaxDatabase::updateStatistics (this=0x2000001c,
context=@0x8641c34, key=@0x8628070, statistics=@0x8628088) at Cursor.hpp:48
#2 0x00901d10 in DbXml::StatisticsWriteCache::updateContainer (this=0x8641bcc,
context=@0x8641c34, container=Internal: global symbol `Container' found in Container.cpp psymtab but not in symtab.
Container may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: Container<type>).
) at /usr/include/c++/3.2.3/bits/stl_tree.h:202
#3 0x0093bacf in DbXml::KeyStash::updateIndex (this=0x8634df8, context=@0x8641c34,
container=0x8630e68) at KeyStash.cpp:210
#4 0x008c72b7 in DbXml::Container::deleteDocument (this=0x8630e68, txn=0x86417f8,
document=@0x8671f38, context=Internal: global symbol `UpdateContext' found in UpdateContext.cpp psymtab but not in symtab.
UpdateContext may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: UpdateContext<type>).
) at Container.cpp:679
#5 0x008d3475 in DeleteDocumentFunctor2::method (this=0x2000001c, container=@0x8630e68,
txn=Internal: global symbol `Transaction' found in Transaction.cpp psymtab but not in symtab.
Transaction may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: Transaction<type>).
) at TransactedContainer.cpp:121
#6 0x008d3149 in DbXml::TransactedContainer::transactedMethod (this=0x8630e68,
txn=0x3d71c8, flags=0, f=@0xb176b470) at TransactedContainer.cpp:217
#7 0x008d2fe8 in DbXml::TransactedContainer::deleteDocument (this=0x8630e68,
txn=0x86417f8, document=Internal: global symbol `Document' found in Document.cpp psymtab but not in symtab.
Document may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: Document<type>).
) at TransactedContainer.cpp:26
#8 0x00906940 in DbXml::XmlContainer::deleteDocument (this=0xbfff8c94, txn=@0xb176b5a0,
document=Internal: global symbol `XmlDocument' found in XmlDocument.cpp psymtab but not in symtab.
XmlDocument may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: XmlDocument<type>).
) at /u/yoava/dbxml-2.2.13/dbxml/include/dbxml/XmlDocument.hpp:72
#9 0x0804a5c0 in DoUpdates (arg=0xbfff8c90) at dbxml_test_6.cpp:99
#10 0x003dedec in start_thread () from /lib/tls/libpthread.so.0
#11 0x0037ea2a in clone () from /lib/tls/libc.so.6
thanks

I have applied them. When applying patch 6 I got an error:
compile3.server 46% patch < patch.2.2.13.6
patch.2.2.13.6: No such file or directory.
compile3.server 47% patch < patch.2.2.13.6
(Stripping trailing CRs from patch.)
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
|*** NsEventGenerator.cpp.orig Thu Dec 8 14:50:50 2005
|--- dbxml/src/dbxml/nodeStore/NsEventGenerator.cppThu Sep 28 17:24:57 2006
File to patch: dbxml/src/dbxml/DbWrapper.hpp
patching file dbxml/src/dbxml/DbWrapper.hpp
Hunk #1 FAILED at 357.
1 out of 1 hunk FAILED -- saving rejects to file dbxml/src/dbxml/DbWrapper.hpp.rej
However this patch does not seem to be lock related.

Help with value change events

I need to be able to use the value change event to handle sorting and control the properties of a multicolumn listbox. I have a slow loop that runs every 10 seconds and acquires new data if it's available. New data is appended directly to the list box. The event structure handles two events. One to change colors of the text when new data is added and another to sort the contents when a user clicks on the column header. The first event seems to work just fine. It only runs when new data is added. The second event is the problem. It runs every time the loop runs and ties up the user interface so that it does not respond.
What am I doing wrong??
By the way, it seems that whatever I am doing wrong crashes LabVIEW while I am
editing the vi. Probably during a partial compile. LabVIEW crashed twice while I was creating this test vi and I don't normally have trouble with LabVIEW crashing. It has crashed in both the transact.cpp and panel.cpp.
Thanks for any help or guidance you can offer.
Attachments:
Event_Handling_Test.vi ‏242 KB

I have made a few quick modifications, see attached.
-- The lower loop should probably be a plain loop, since the timing is done by the event structure.
-- You cannot use a shift register in the upper loop if you want the acquired list to remain sorted.
Sorry, I am on vacation in the middle of nowhere and only spend a few minutes on this. There are many improvements possible.
LabVIEW Champion . Do more with less code and in less time .
Attachments:
Event_Handling_TestMOD.vi ‏200 KB

I'm trying to build a project that's historically been built in Labview 10.

Hi there,
I'm taking over a work project that's been previously written and built in Labview 10. I've started with and am getting my feet wet in Labview 2014 SP1. The vi runs just fine, but building it for an executable seems to crash. Namely, this report:
DAbort 0xA8CFE759 in bdpopup.cpp
Version: 14.0.1 (32-bit)
Possible Cause: C:\Program Files (x86)\National Instruments\LabVIEW 2014\vi.lib\AppBuilder\Engine\AB_Engine_Disconnect_Typedefs.vi
I'm not sure if this is a old revision not playing nice with a newer compiler issue, or if I've neglected something in my setup. Any advice for me? I'm happy to post code, but it's a 160 MB project. Is that too large to throw up here?
Thank you,
Nick

Nick1978 wrote:
Hi Bob, thanks for the reply.
Yeah, sorry. Labview 2010. I have a google drive I could throw it on.
Unfortunately, the only message I get is the LabView Crash Reporter telling me that Labview 2014 encountered a problem and needed to close.
I see some stuff about Labview SP1 32bit (what I'm running) having trouble with installers on a 64 bit os (I'm Win7 64.) Maybe that's an issue.
Uploading to my google drive now. Thanks again.
I would wager that a large majority of LabVIEW users are running 32-bit LabVIEW on 64-bit Windows 7 (or 8.x). The "issue" seems to come when you try to run 64-bit LabVIEW ...
If you put it on a Google Drive, you'll need to either post how to get it, or if you have any concerns about pointing the Forum to your Drive, you could send a Private Message to selected Forum Members saying "Could you please take a look at this and suggest why I can't build it using LabVIEW 2014 SP1?".
Bob Schor

Creating a numerical table multiple precision

Hi,
I am kinda new at this but I was wondering if it was possible to create a numeric table with multiple precisions. To explain better, I have a table with two columns and I would like the first column to be with precision zero and the other with precision 2.
Attached is the Vi that I was using where I converted the string from the table to a numerica array, converted the values to the required precision I wanted, and then converted the numeric array back into a string to place in the table. However this caused labview to keep crashing on me, indicating "Fatal Internal Error : " transact.cpp", line 1323"
Some other options I have tried are using the key down? event option that forced the user to only type in numbers in the table, however I still had no control over the precision. I have also tried to use flat sequences, etc... but to no avail.
Thanks in advance for any help
Reza
Attachments:
table.vi ‏19 KB

Well, "delete from array" is probably not the right tool to get two colums of a 2D array, right? Use "index array" instead.
Or you could just do autoindexing as in the attached code draft.
(btw: I cannot duplicate the crash with your VI. Any special instructions?)
Message Edited by altenbach on 07-10-2007 02:32 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
tableMOD.png ‏8 KB
tableMOD.vi ‏17 KB

Labview 2011 FDS (64bit) crashes when saving a vi with MATLAB node

After running a vi which includes a MATLAB node, the vi cannot be saved, because Labview crashes every time with error: "DAbort 0x1A7102DF in fpsane.cpp".
Why does a MATLAB node with simple array I/O corrupt LABVIEW's sanity ???
I have attached a minimum configuration, which gives a reliable crash. First run, then push save.
Configuration: Windows 7 (new installation), Labview FDS (64bit), MATLAB (64bit)

Amd1480 wrote:
did anybody could solve or got a work arround this problem?
I am getting the same error code when I use the Call Library Function to call external DLLs in my application.
I am using the following system configuration:
- Windows 7 32bit with SP1
- LabVIEW PDS 2011 32bit
Additionally to this error I am getting the following message (Ausnahme: Access violation (0xC0000005) bei EIP=0x00C0503F) (see attachments)
Note: calling the same DLLs using previous LabVIEW versions (8.2) works fine.
When such errors happen in an application that uses the Call Library Node, you can be almost certain that it is a problem in how the Call Library Node was configured (wrong!) or a bug in the DLL. That you happen to see this error, only means that the external code happend to overwrite memory that it was not supposed to do, and that memory happened to be some data structure that LabVIEW uses to represent some front panel element. That it didn't happen in 8.2 doesn't mean that it didn't have that error there too, only that it overwrote some different memory location, that had unluckily for you no visible consequences.
For all other cases with no Call Library Node included, it means that the VIs front panel resource got somehow damaged (and yes this could also happen from running the VI in an application with misbehaving Call Library Node, and then saving the VI). The most easy solution is to rewrite the VI, another option is to try to force a recompile with the Ctrl button pressed and then activating the run button in the VI toolbar. Other than that there is little we normal users can do. The only people who can do more here are the LabVIEW developers who can look inside the VI and identify the damaged data structure and repair it, but that is a lot of work and time, and NI doesn't commit to doing this normally.

Open XML DB hung

Hello,
On one of our nodes, we are observing a thread locked on open XML DB. The thread back trace after attaching to the process is as follows
#0 0x00002b46a2e47f76 in __select_nocancel () from /lib64/tls/libc.so.6
#1 0x00002b46a14a5eeb in __os_sleep () from /usr/local/maui/lib/libdb_cxx-4.5.so
#2 0x00002b46a14364be in __op_rep_enter () from /usr/local/maui/lib/libdb_cxx-4.5.so
#3 0x00002b46a14ab495 in __txn_begin_pp () from /usr/local/maui/lib/libdb_cxx-4.5.so
#4 0x00002b46a13e53ec in DbEnv::txn_begin () from /usr/local/maui/lib/libdb_cxx-4.5.so
#5 0x00002b46a1722a5f in Transaction (this=0x90cea0, mgr=@0x0, flags=0) at Transaction.cpp:40
#6 0x00002b46a171ad14 in DbXml::XmlManager::createTransaction (this=0x844fc0, flags=0) at XmlManager.cpp:654
#7 0x00002b46a1e2e1a0 in BDBXmlDbEnv::openXmlDb (this=0x827d10, dbSpec=@0x43b11b00, stat=@0x43b11a64, prop=0xffffffffffffffff)
Do let me know if more information is needed

This can sometimes happen during "internal init" at the client,
especially if the master goes idle (i.e., the application is not
making any new updates), although in older versions of Berkeley DB
there was a bug or two which caused it to also happen under certain
race conditions.
If you are able to reproduce this hang, can you please turn on verbose
replication message diagnostic output? Also, is the master continuing
to perform update transactions during this time? If not, it would be
useful to try having it do so, even if it means running the
occasional extra "dummy" transaction.
Alan Bram
Oracle

Looks like an unhandled exception

I am using 2.4.14, I see the following crash. We catch exceptions in our code.
(gdb) bt
#0 0x00002afcd9344a3d in *__GI_raise (sig=22638)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1 0x00002afcd9345f1e in *__GI_abort () at ../sysdeps/generic/abort.c:88
#2 0x00002afcd8f45ba8 in __gnu_cxx::__verbose_terminate_handler ()
from /usr/lib64/libstdc++.so.6
#3 0x00002afcd8f43d86 in __cxa_call_unexpected () from
/usr/lib64/libstdc++.so.6
#4 0x00002afcd8f43c88 in __gxx_personality_v0 () from
/usr/lib64/libstdc++.so.6
#5 0x00002afcd92119af in UnwindFindEnclosingFunction () from
/usr/lib64/libgcc_s.so.1
#6 0x00002afcd9211e1b in UnwindResume () from /usr/lib64/libgcc_s.so.1
#7 0x00002afcd7bc5283 in DbXml::Transaction::abort (this=0x2aaab4790a90)
at Transaction.cpp:99
#8 0x00002afcd7bc5367 in ~TransactionGuard (this=0x47b19a30) at
Transaction.cpp:362
#9 0x00002afcd7b4ef3b in DbXml::Container::updateDocument (this=0xb77250,
txn=0x2aaab4d2f8f0, document=@0x2aaab474bf40, context=@0x2aaab4acd720)
at Container.cpp:1176
#10 0x00002afcd7ba8d09 in DbXml::XmlContainer::updateDocument (this=0xb9bb58,
txn=@0x47b19b30, document=@0x47b19b50, context=@0xffffffffffffffff)
at XmlDocument.hpp:75
#11 0x00002afcd8382bed in BDBXmlDb::updateXmlDocument (this=0xb9bb50,
key=@0x47b19bf0, doc=
{_M_ptr = 0x40}, txn=0x47b19b20)
at

Hi George,
I guess we need kitchen sink catch at the end. I should have caught this earlier.
Here is what the code looks like around the updateDocument call.
try {
dbContainer.updateDocument(dbTrans, dbXmlDoc, dbCtx);
catch (DbXml::XmlException& e) {
if (e.getDbErrno() == DB_LOCK_DEADLOCK) {
return DB_DEADLOCK;
if (e.getDbErrno() == DB_REP_HANDLE_DEAD) {
env->restartProcess("INVALID HANDLE");
return DB_HANDLE_DEAD;
if (e.getExceptionCode() == DbXml::XmlException::DOCUMENT_NOT_FOUND){
return DB_RECORD_NOTFOUND;
else {
return DB_INTERNAL_ERR;
}

Error: [129]: transaction rolled back by an internal error: [129] transaction rolled back by an internal error: exception 141000274: exception 141000274: TRexUtils/ParallelDispatcher.cpp:275 message not found; $message$=

Hello Gurus,
I have a couple of calculation views in HANA and each of them has text fields (like Employee Name, Country Name etc.).
As part of my project requirement, I have join those two views and get all the fields that exist in them.
When I am doing so, I am getting a weird error as shown below.
Error: [129]: transaction rolled back by an internal error: [129] transaction rolled back by an internal error: exception 141000274: exception 141000274:
TRexUtils/ParallelDispatcher.cpp:275
message not found; $message$='TSR HTKD JFSDFM'
Please check lines: 59,
Upon, researching further, I could see that the value 'TSR HTKD JFSDFM' is the value in text field of Employee Name.
I did try to increase the length of the field and change the data types but nothing has worked.
Could you please help me in getting this one resolved.
Thanks,
Raviteja

Hi,
I am exactly facing the same issue:
Error: [129]: transaction rolled back by an internal error: [129] transaction rolled back by an internal error: exception 141000274:
But i found a fix :-) .....
This may be a very late reply but it would help people who desperately searching for an answer for this issue.
I used CAST function .. The problem is, we are selecting data from table and of course we dont know the size of the data (attribute) @ runtime. We assign the length by looking at the table attr length or view op attr length. But what happens is the junk data which exceeds the limit of the allocated space hence we get this error.
So i used CAST function to truncate the excess junk values (may be spaces).
Example:
I have a ATTR view of date in the format YYYY-MM-DD which means 10 char size.
In my CALC view I have created date OP column of VARCHAR(10) but I get the above error for no reason. Eventhoug i am 100% sure about my ATTR date would be max of 10 char my CALC view is failing @ runtime.
So i did a CAST on date as CAST(my_date as varchar(10)) and the magic happend. It works .......
But you need to be careful in using this because if you use CAST you may lose data. Careful. In my case i dont.
Somebody from HANA team should look at this issue from SAP and solve this. I am sure it is a serious bug from HANA (eventhough i am using SAP HANA SP09 Rev 92 the most latest as of today !!!!!!!!!! )
Enjoy....
Thanks & Regards
Prakash K

Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph

NOTE: This IS a duplicate post from the Breakpoint. Text slightly changed. The post in Breakpoint can be deleted. All comments should be placed in this thread.
I resolved the "Fatal Internal Error: "image.cpp", line 13192 when trying to insert a cursor to graph", but would like to share to find out if others have seen this and to determine whether this is a bug, or if it's time to redo my PC, or buy a new one..
I have an existing graphs (qt 6) which originally had 2 cursors. This occurred while trying to add the third cursor.
Up until attempting to add the last cursor, the program worked great, and I had been running tests for a while. However, I do recall seeing this problem when creating the original cursors, but not to this extent. Plus I don't remember the original error message from that time.
I needed to add one more cursor to the existing graphs. As soon as I add a new cursor and set it's properties, I get a nasty error message and without warning LV8.2 simply closes itself (well, the only warning was the error message. Tried it 3 times, same result.
Here are the steps:
Shut down the PC, went for a coffee, rebooted the PC. Opened the LV project, opened the VI. Immediately went to the graph properties to add the new cursor by doing the following steps:
Right click graph indicator icon on block diagram.
Select Properties.
Click on cursor tab.
Click on Add
Select Cursor 2 (3rd one, newly created)
Change color
Select cursor as a line
Remove checkmark for "show cursor"
Click OK
I need to do this to 3 other graphs, same steps. And as soon as I get to the step before clicking OK, I get the error message.
I managed to get an additional one done, by immediately saving after each step (yep going in & out of the properties). But I've had this problem before when creating the first two cursors.
Is it a bug? Anyone else seen this? Using LV8.2. And the message is right about LOOSING ALL unsaved work!!!!
Here are more observations:
Tried creating a new one on the second graph. As soon as I clicked on the color, it crashed!
See the error explanation below. It is really clear, now anyone can solve it    LOL!!... According to the error log, there's a bad image out there
.\manager\image.cpp(13192) : DAbort: bad image in ValidateImage
$Id: //labview/branches/Europa/dev/source/manager/image.cpp#47 $
0x007A81E8 - LabVIEW <unknown> + 0
0x007A7BDB - LabVIEW <unknown> + 0
0x00829D74 - LabVIEW <unknown> + 0
0x008546CD - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0081B9C8 - LabVIEW <unknown> + 0
0x0081EB9A - LabVIEW <unknown> + 0
0x0084D9D4 - LabVIEW <unknown> + 0
0x00854663 - LabVIEW <unknown> + 0
0x00C054E6 - LabVIEW <unknown> + 0
0x0085F7A1 - LabVIEW <unknown> + 0
0x00BBACDD - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
0x0085AA46 - LabVIEW <unknown> + 0
0x00C06A2F - LabVIEW <unknown> + 0
I observed the title bar after making changes to the properties. I noticed that 3 out of 4 times, while changing the properties of the graphs to include the cursor, and saving after each & every step, that there were no stars appearing on the title bar to indicate "unsaved changes". Saving was also much slower than usual. I suspect, the program never got to placing the star before saving occurred. However, I am noting everything.
After creating the cursors, saving was and is normal, and the program runs well..   I have run tests without problems.
Does anyone have a clue at what causes this? Has anyone seen this before?
Thanks,
RayR

Hi Donovan,
I can't remember seeing this elsewhere. When I get a chance, I'll create a new (blank) vi with new graphs and will repeat the steps.
I will let you know if I see this in the new vi.
Thanks!
RayR

DAbort 0x26550A7E in transact.cpp

Similar Messages

Maybe you are looking for