LVCompare and LVMerge Crashes

[Zxero88]

Hello ladies and gentlemen! Prepare yourselves for a massive wall of text. Thank you in advance.

First time poster, long time lurker. Over the last decade I have found answers to a myriad of Labview related questions I've had on these forums, and I'm hoping some of you can help me out with my current conundrum.

I've a solo developer for a large labview based automation project. I have worked with other labview developers in the past, but we've always kept what we were working on very compartmentalized because nobody ever wanted to deal with LVMerge. At the time they all said Labview effectively had zero way to merge VIs.

Since those old days (9 years ago) we've come a long way. Unfortunately like many engineers I am horrible about UI/UX design - I'm trying to fix basic functionality, I don't care that you can't find the button (at least I don't care right then). But because of how solid the software is getting we're finally in a good position to start dedicating time and effort into improving our UI flow and design. 

So in the run up to this, and knowing I had basically zero experience with LVMerge/Compare except that the previous developers considered it "impossible", I did a few tests. My goal was to continue some development in the block diagram of the main top level VI in my own git branch, while another developer worked on UX changes on a second git branch. Then when he was ready we'd merge everything back together. All of his changes were focused on the Front Panel - he never opened the block diagram once. He was moving things, resizing things, changing captions and boolean texts, but never labels, and then adding various decorations as he wanted for clarity and organization.

My initial test merges worked flawlessly. I was surprised how easy my small merges worked. From there he tinkered away when he could over 4ish weeks on the UI and I kept my usual pace on the main top level working on various bugs. I tried to limit what I was doing in the top level - most of the block diagram changes I made were cosmetic. It needed some TLC.

Anyway fast forward and now we're ready to merge everything back together and ... I can't. I cannot get it to work. I've tried so much stuff. At first the errors were almost always during the LVCompare phase, usually about an insane block diagram object on the "base" vi. I'm familiar with heap peak so after a crash I'd comb the error log as well as I could (wish that thing had some documentation) and then try to find the offending object and fix it. More often then not I wouldn't see an issue with the object at all, and lots of the advice online is "just delete and remake the object" but I hate that solution because it means I fundamentally don't understand the actual problem, and when I'm merging three different versions of a big VI that gets tough to do.

I've been experimenting with the tools, and eventually turned off auto resolve. Okay cool that would get me through the compare stage and actually open LVMerge where I could select which versions of things I wanted. From here it became a game of cat and mouse where I go through changes one by one till I get a crash, investigate, fix, change something related to said crash, and then run it again. This has been time (and sanity) consuming.

It never worked, and eventually I got stuck on a merge change that I couldn't even identify what it was changing between the three, but I know that no matter which I select it crashes. I've kept trying various things since then.

• Resizing the tab control positions to be exactly the same
• Deleting a few FP objects on the base and FP update versions that I had removed when making BP changes on my version
• Adding a few objects I created for the same reason
• Added all 3 versions of the VI to the main most up to date project, opening and running them all to make sure there are no serious insane objects that are breaking them. They all run.

This is by no means an exhaustive list of everything I've tried, but its what comes to mind right now as the major tries. Currently the state I'm in is that when I run it with all 3 versions with all the changes from above made to them, I can't get through the Compare stage because it crashes with a insane object error about "undo.cpp" which makes zero sense to me. What is it undoing? I tried limiting the number of Undos in LV settings, that didnt help, I tried increasing the limit greatly, that also didn't work (maybe didn't increase enough? Trying that now). 

I'm really deep in the weeds on this one now, and I would love some fresh perspectives. What's probably going to happen is that I'm going to write it all off as a lesson, and we'll just have the UI dev make his changes again on my current most up to date version - but I would really love to figure out the compare and merge process, and best practices for using it. The documentation for these is abysmal. There's basically nothing. I could probably pay for NI's annual subscription and maybe get some direct help from them but I had it out pretty big with some NI sales guys a few years ago when they transitioned away from perpetual licenses to the subscription model, and I don't want to pay them on principle; but I will if needed.

Ultimately even if we do the changes again, I'd still like some best practices on where we went wrong and how to avoid this in the future. We're growing fast, and I could see having another full time labview developer working with me in the future and would love to come away from this with as many answers as possible on how to work in a team on labview binary files. 

If you've made it this far all I can say is thank you. Now please send help.

PS: some info I should of added

• we use Labview 2021. I don't think we're on SP1, I don't remember why not, and I am willing to try updating.
  • also willing to pay the sub and just upgrade to 2025, but not without good reason like someone tells me all about how they solved so many issues with Compare/Merge in the last 4 years and its going to be so much better
• I'm attaching my most recent error log from the crash I had last night. Its a doozy, reporting a TON of objects on both the FP and BP as insane.

 

lvlog2025-08-11-15-32-09.txt

Edited August 11 by Zxero88
replaced log file with one that doesn't have personal identifying info

[LogMAN]

Welcome to the active side of LAVA!

On 8/11/2025 at 10:43 PM, Zxero88 said:

I could probably pay for NI's annual subscription and maybe get some direct help from them but I had it out pretty big with some NI sales guys a few years ago when they transitioned away from perpetual licenses to the subscription model, and I don't want to pay them on principle; but I will if needed.

You may be happy to learn that perpetual licenses are back: https://www.ni.com/en/shop/labview/select-edition.html

On 8/11/2025 at 10:43 PM, Zxero88 said:

Ultimately even if we do the changes again, I'd still like some best practices on where we went wrong and how to avoid this in the future. We're growing fast, and I could see having another full time labview developer working with me in the future and would love to come away from this with as many answers as possible on how to work in a team on labview binary files. 

Binary files are always problematic when merging. Even LVMerge does not get it right all the time, especially when the differences are too large, which gives you the first clues:

• Whenever possible, avoid merges - no merge means no merge conflicts
• Establish a process to avoid merges - perhaps finish implementing the functional part first, then hand it off to the UX designer.
• Establish an environment of clear communication among developers - telling a colleague to wait 5 minutes for your work to finish so that they can base their work on yours is a very effective way to avoid conflicts in the first place.
• Merge changes in small, iterative cycles - this reduces the chances of merge conflicts and insane objects
• If more than one developer needs to touch the same code at the same time, review your architecture. Split large VIs into smaller SubVIs, build reusable components, separate concerns, etc...

In my team we seldomly need to merge (perhaps once or twice in the past 10 years). We split the project into functional groups with clear boundaries. The lead developer is responsible for ensuring that the boundaries are maintained. When a team member needs to make changes that affect others, we first merge everyone's branches, then do the change, then continue with normal work. At least for us this has proven very effective.

On 8/11/2025 at 10:43 PM, Zxero88 said:

we use Labview 2021. I don't think we're on SP1, I don't remember why not, and I am willing to try updating.

• also willing to pay the sub and just upgrade to 2025, but not without good reason like someone tells me all about how they solved so many issues with Compare/Merge in the last 4 years and its going to be so much better

I can't say much about LV2021 because I'm still working with LV2019 but in general the SP1 version is more stable and reliable. Maybe take a look at the bug fixes and known issues to help you make a decision: https://www.ni.com/en/support/documentation/release-notes/product.labview.html?version=2021-sp1

For your merge issues, however, it will most likely make no difference.

Since LV2024Q1, however, NI has made considerable changes under the hood, including new tooling for diff and merge: 

• Improvements to Comparing VIs
• Changes to Compare VIs and Other LabVIEW Files
• Generate VI Comparison Reports with the LabVIEW Command Line Interface

Perhaps more useful is the new feature that allows you to open a project without changing the save version, which means you can edit and save VIs in earlier versions (as far back as 2017) without having to go through any extra steps.

This also means you could try to merge using LV2025Q3 and keep the merged files saved for LV2021.

The chances are slim that the errors can be resolved in newer versions but it might be worth a try.

And you don't need a license for that. You can evaluate LabVIEW for a couple of days (I believe up to 30 days).

*cough* Community Edition *cough* - pardon me 

[lv_dev]

LVCompare CRASHES

In my attempt to comapare a VI that is quite bigger than the avarage VI (about 550 KBytes), LabVIEW always crashes after some loading time. Comparing other (smaller) VIs than this one works perfectly.

Output I get:
LabVIEW caught fatal signal
25.1f0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x41
Segmentation fault (core dumped)

(Yes I am using LabVIEW on Linux, which is quite special on its own)
As you may see I am using LabVIEW 25Q1 Pro and this issue with the crashing LVCompare still remains.

I already wrote a ticket to NI and gave them some information, and now they are investigating this issue.

Edited 2 hours ago by lv_dev