Grrr... Xilinx compile failures

[Daklu]

---

without an in-house reproducing case, "fixes" are often a shot in the dark based off of some crazy theory... I'm not saying I hope it happens to you again, but I would like help track down the bug if it does  

---

Yeah, I get it--we're all software developers here.    I get all sorts of reported bugs from customers I can't repro.  90% of the time it's something wonky on their system I have no control over.  (Just yesterday I spent an hour on the phone with an FSE troubleshooting an installed system.  Turns out the cameralink cable wasn't plugged into the pc. )  9% of the time their repro case is incomplete.  0.9% of the time I can repro the problem and find the bug.

---

Edit: On a hunch... Are you operating out of a DropBox or other auto-syncing web/network magic folder?

---

I do use DropBox, but this project is not in a DropBox or any other kind of auto-sync folder.

[Daklu]

---

I did speak with the AE you are working with through that SR, so he'll keep me up to date if you run into anything else.

---

I asked him to move all our conversations to the forum.  It's easier for me to manage when there's only one conversation.  🙂

Anyway... something new did occur, I have no idea if it's related or not.  The project I am working on is in LV2012.  I attempted to open a project in 2012 a colleague wrote using 2011.  When I went to open his fpga vi, I got this error:

I clicked okay and it continued loading sub vis, then I got this error.

I have seen the second error before when I manipulate the input or output nodes of a timed loop structure, which my colleague has in his fpga vis.  They do not seem to cause any problems beyond being annoying and my fpga vi doesn't use timed loops anyway, so... ?

Like I said, I don't know if any of these errors are related to my compile problems, or even if these two problems are related to each other.  It's just new information that might be useful.

[GregFreeman]

I've had this issue before too when upgrading (I think from 2010 to 2011). I assumed it was an xnode backwards compatibility issue and just dropped new read/write nodes down. I'd be interested in this too haha. You're hitting on all the issues and points I never followed up with! Keep going, I'm rooting for you!

[Daklu]

---

...and my fpga vi doesn't use timed loops anyway, so... ?

---

Ha!  Turns out I was wrong--there is a timed loop in my fpga vi.  It's just in that section of code I never pay attention to. 

[T-REX$]

Does a force recompile help (<ctrl> + <shift> + run) or a mass compile of the project? I don't think the errors are related in anyway, but if I can get a reproducing case, I can get the bug report to the appropriate developer (I like making dumb errors go away). It might help if you always use the seperate source from compiled code option in the VI properties... But that should probably be saved as a topic for another thread    Even if it doesn't reproduce, a crash dump can also point us down the right path if one was generated by that error.

Now... not to deflect this barrage of problems here... how old is your computer, and have you done a HD diagnostics scan (chkdsk) ever? Do other applications have strange behavior too, or just LabVIEW? I just want to rule out the obvious before going too far down the rabbit hole. I looked at some of the errors in the compiler log, and a couple of the characters I can identify as wrong have exactly 1 bit flipped (not shifted) in the ascii value. I've seen hard drive failures do some crazy things...

[tannerite]

I am with T-REX$ in that any dump files would be helpful in determining where the error is coming from. And since one bit is flipped, that could definitely indicate that a hard drive is failing, or may be corrupted.

Best,

tannerite

[Daklu]

Sorry for the late reply.  The thread update email got lost among the flurry of community thread update messages.

FYI, my mb, cpu, and memory are less than a year old, other components are a bit older.  As a matter of fact, I have seen an uptick in BSOD occurrences over the last several months.  I ran chkdsk at the time, but it didn't turn up anything particularly useful.  Based on your feedback I ran chkdsk again with the /R switch.  The log file indicates a few issues with the index and orphaned files, but no bad sectors.  However, some of the other MS tools are indicating hard disk problems.

I'll continue digging.  In the meantime I have a laptop I can use for Labview dev.

[Daklu]

To wrap up this particular issue, I finally found the root cause of this problem and it wasn't the hard drive.  It turns out one of my memory sticks was failing and not setting bit 1 correctly.  I've heard memory sticks can fail in the field, but in 20+ years of computing I've never actually seen one go bad.  If T-REX hadn't mentioned the single flipped bit I probably wouldn't have thought to test the memory.  Thanks!

The good news:

-I purchased a new pair of SSD drives before I discovered the real problem.  (Nice!)

-Corsair memory is waranteed for life, so I had no trouble getting a set of replacements on RMA.

The bad news:

-I accidentally toasted my motherboard while troubleshooting by inserting a DIMM the wrong way.  It completely burned up one of the fat ground traces on the backside.  Yes, I know the DIMM sockets are keyed to prevent stupid people from doing stupid things, but I was clever enough to overcome that particular obstacle.  (That's what I get for working with inadequate light.)

[GregFreeman]

---

@Daklu wrote:

  (That's what I get for working with inadequate light.)

---

"inadequate light" or user error?