"Assertion failed" messages : strange programming practice at Adobe

  • 1
  • Problem
  • Updated 1 year ago

Hi,

There's something that is bothering me with Lightroom. I'm currently trying to help a user who has problems when launching LR. He gets an "assertion failed" message and that's it. We'll certainly fix that but this kind of message just raises a question...

Assertions are small tests inserted in a program's code in order to verify that some condition is met when reaching a given part of the code during execution. If the condition is not met (the assertion failed), then the program immediately stops.

Assertions are used by developers when testing and debugging their code. Assertions are useless when the code is considered OK. During development, the program is compiled in "debug mode" and the assertions are embedded. When the program is considered ready, the compiler is switched to "release mode" and the assertions in the source code are ignored and not embedded in the final code. Why ? Because this code needs to be executed only during development.

Since the Lightroom users are sometimes getting these "assertion failed" messages, this means that the delivered code was compiled in debug mode, not in release mode. Since this code contains tests that are useful only during development, this more or less affects performance (because the assertion code is executed although it's not necessary).

Conclusion :

- If the distribution of code compiled in debug mode is a programming mistake, there's something to fix in the project management.

- If this is done voluntarily, this is strange programming practice. The "assertion failed" message doesn't give any indication about what caused the program crash (because the assertion can only be handled in debug mode when the program is run under the control of a debugger). So the embedded test code is useless anyway (from a user's point of view).

It's important to note that when an assertion fails, this doesn't always mean that something went wrong. The assertion was inserted by the developer because he wanted to check something at some moment during the development phase. The assertion may fail when the program runs in the field because the test was related to the developer's environment. So a debug assertion may fail in the field while there's absolutely no problem (but the program will stop anyway). This is why the distributed code should always be compiled in release mode.

Since performance problems are a hot topic in LR, I'm wondering why the developers would want to make things even worse by distributing a version of a program containing non functional code. It's a common mistake among junior developers to forget to switch to release mode when the code is considered ready for delivery. But since these errors have been reported so many times, the project managers are certainly aware of this.

So why are Adobe still distributing code compiled in debug mode ?

Photo of Patrick Philippot

Patrick Philippot

  • 407 Posts
  • 82 Reply Likes
  • confused

Posted 1 year ago

  • 1
Photo of David Fabian

David Fabian

  • 77 Posts
  • 18 Reply Likes
Can you also share some specifics about the versions (Lightroom, Windows, etc...).  Just doing some basic searched for "Assertion Failed" several postings showed up from older versions of the Visual C++ runtime libraries and Lightroom (ver 5.x).
Photo of Patrick Philippot

Patrick Philippot

  • 407 Posts
  • 82 Reply Likes
Hi David,

The problem I'm currently trying to handle for this user occurs in Lightroom 6 / Windows 7. There are reports indicating that the "assertion failed" message can also appear under Windows 10 / Lightroom 6.
Photo of Patrick Philippot

Patrick Philippot

  • 407 Posts
  • 82 Reply Likes
Just to be clear : this thread is not about the problem I'm trying to fix for this user. The actual problem is that the LR6 delivered code is still emitting these "assertion failed" messages and that it should not. I can't see any good reason for this. Debug assertions are a development tool and should not survive in the delivered code.
Photo of David Fabian

David Fabian

  • 77 Posts
  • 18 Reply Likes
Thanks for the reply.  I saw some other postings to the same error that related to missing default folders (For Example:  https://forums.adobe.com/message/8497594#8497594).  Not sure if this would help your user.
Photo of David Fabian

David Fabian

  • 77 Posts
  • 18 Reply Likes
I understand but when LR starts it wants certain resources on the workstation.  If they aren't available then the error condition would occur.  Since I have never encountered anyone with this error before, I would like to get a better understanding if this is a repeatable problem and what it would take to generate the error.  Permissions, disk space, RAM, other applications?
Photo of Patrick Philippot

Patrick Philippot

  • 406 Posts
  • 80 Reply Likes
I understand but when LR starts it wants certain resources on the workstation.
Yes, but assertions are not the way to check this and have never been. As explained above, assertions are debugging tools. If the availability of a given resource must be checked in any case (debug or release version), then standard code must be used. For example, if LR absolutely needs a given folder to be present, the code sequence would be as follows :

1. Check presence of folder using the relevant APIs.
2. If folder present then continue
3. If not, send a clear message to the user explaining that the program cannot continue without this folder being present. The code could possibly propose to the user to create this folder automatically or use exception handling to recover.

In no case the target folder being missing should cause a program crash without any further explanation given to the user. But that's exactly what assertions do.

So I repeat, assertions should never be present in the code delivered to the users. Instead, such conditions should be handled using exceptions, which would give the developer the opportunity to recover from the error and suggest adequate actions to the user.

In order to determine the origin of a problem, the code could also generate logs on demand but LR is missing such a feature.
(Edited)
Photo of Jim MSP

Jim MSP

  • 9 Posts
  • 2 Reply Likes
See another example of the assertion error in LR CC when accessing Flickr. https://www.lightroomforums.net/threads/error-when-removing-photos-from-flickr.31544/#post-1212541
Photo of Simon Chen

Simon Chen, Principal Computer Scientist

  • 1490 Posts
  • 471 Reply Likes
The asserts are LUA runtime exceptions (LUA is the runtime programming language used by Lightroom) that typically indicate some abnormal condition has occurred in the code. In the normal case, the developers would employ defensive programming techniques to watch out for these abnormal conditions and handle them appropriately as they arise. But unexpected cases still happen, they are rare and typically involve cases that the code does not anticipate. Most often, they expose bugs that needs to be fixed. So they are conditions that developers wants to know when they occur.

When Lr encounters such runtime exceptions, it can generate the tracebacks log if it is enabled (see https://forums.adobe.com/thread/925598) so that developers can use the traceback logs to know exactly where (the callstack) and why the assert happened. In such cases, Adobe can be aware of the issue and fix the real underlying bugs, rather than keep it unnoticed.
(Edited)
Photo of Patrick Philippot

Patrick Philippot

  • 407 Posts
  • 82 Reply Likes

Hi Simon,

So, if I understand you well, you are telling me that LUA doesn't have Structured Exception Handling (actually, I already know that). Therefore a routine for catching unhandled exceptions cannot be inserted in the code and assertions are used instead.

I will not discuss the choice of LUA for developing LR (especially for a program that needs performance). There's no chance to change anything about that anyway. However, since LUA has limited capabilities regarding error handling, LR should have its own built-in mechanisms instead of relying on DbgView (or at least use DbgView in a transparent way).

Unless I'm missing something obvious, I have never seen any directive about the use of DbgView when a user reported an "assertion failed" message. When LR crashes with such a message, it should display instructions as described in the thread you mentioned. This would be the bare minimum. Also, a built-in log mechanism would be easier for the user. Instead of asking the user to add an argument on the command line, a key combo (like the one used to reset the preferences) should be available in order to launch LR in debug/tracing mode. DbgView could be a part of the distribution and could be launched as soon as that key combo has been detected, when the process begins to execute.

In other words : don't think developer, think user.

If you want information about the cause of the assertion failure, you need to make the reporting easy for the user. That's not something that is difficult to implement.

[NOT OFF-TOPIC]

By the way, now that someone from the development staff is talking to us, I have a question about those bugs that are lasting since years and that are still waiting for a fix. A good example is this one which is lasting since version 1 :

Lightroom: Wrong timestamp stored in catalog causing wrong metadata status (all Windows versions) | Photoshop Family Cus... 

This bug has been reported multiple times, is identified and probably easy to fix. But we continue to be bothered by these endless warnings about the metadata status allegedly not up-to-date. This is just an example, we have a lot of such bugs waiting to be fixed since years (like the bugs related to a failed assertion as discussed above) and not only in Lightroom. I'm questioning the way bugs are managed at Adobe. Once a bug has been declared as "minor", we can rest assured at 90% that it will never be fixed.

I have already suggested to handle the priority list another way : the "todo" list should be worked on from both ends. The majority of available development/maintenance resources should be dedicated to the most urgent bugs but some developers should work on the low priority bugs which are most of the time very easy to fix. Or the maintenance developers should spend a part of their time looking at these low priority bugs what they obviously never do. If you think "customer satisfaction", you know that these allegedly minor but unfixed bugs are those who are giving a bad feeling about code quality. So they should be handled seriously.