CDR Tickets

Yes, please post the log file to this ticket. Do what you can to reproduce the crash. In any case, I have opened a ticket with the vendor, passing along the information I could from your description and the screenshot.

~volker I filed a bug report for this crash, and they asked if this might be another instance in which our CSS doesn't comply with the stricter checking performed by XM17. Could you take a look and see if there are other places in our CSS which might need the same tweaking you applied to the earlier culprit?

cdr-client.log

I have attached the lo file and will try to reproduce the error when I log back into the CDR. Thanks!

@volker - from the logs it appears that the last document opened before the crash was 593427, which is an English Screening summary (patient version). That's also the document with the focus in the screenshot. Just in case this helps in figuring out which CSS to look at.

I was able to reproduce the error with a citation document - CDR0000762179. It happens when I try to switch from Normal View to Tags On View. It happens each time I do that and clicking on Ignore this time around, did not crash XMetal. Unfortunately, I am not able to reproduce this same behavior with a different documents but I will keep trying. Let me know if you're still online and want to see it. 

Let's first see what ~volker has to say when he weighs in.

I did a little digging myself. It looks like there are some parallels with XMetaL ticket #00014806, but the explanation for that crash doesn't appear to completely account for this case. William's report implicates the Citation and the Summary CSS. I have started with the Citation CSS, and here's what I found.

The CSS file had two elements in the list given the "{}display: block{}" rule which were each triggering the crash: MedlinePgn and {}FullTextArticle{}. Commenting out both of those eliminated the crash. The MedlinePgn element does match the condition causing the crash in #00014806, and I was able to uncomment that element without the crash by adding its enclosing Pagination element to the list of block elements. However, that doesn't work for the FullTextArticle element, which is a top-level child of {}Citation{}. It would be very strange if XMetaL were defaulting the root element In the CSS file, {}Citation{}, to "inline," but I tried anyway, adding that element to the list of block elements. Didn't eliminate the crash. So I gave their developers the CSS involved for this instance, along with a sample document and its DTD, and I'm hoping they'll be able to figure out what's going on with this case.

On to the Summary CSS.

It looks like we're going to have to dig into the CSS for all our document types, ~volker.

I had a brainstorm for the Summary case, triggered by seeing that the Summary document William was viewing had so much revision markup. I brought up the same document, and was able to eliminate the crash by adding the following to the CSS for Summary documents:

Summary > Insertion,
Summary > Deletion,
SummaryMetaData > Insertion,
SummaryMetaData > Deletion,
SummaryKeyWords > Insertion,
SummaryKeyWords > Deletion,
    { display: block; }

Since we now know that XMetaL 17 defaults any element not explicitly assigned a display rule as inline that means that Insertion and Deletion elements default to {}inline{}. That works fine when those elements are used to wrap phrases within running text, but not so well when they are used to wrap block-display elements. This addition was sufficient to eliminate the crash for this particular example, but it seems likely that what I've added doesn't cover all the wrappers which contain block-level elements. And that's just for Summaries. Our CSS is about to get much trickier. 🙁

I suspect that this approach has always been there, but it's been masked from us because the test was contained in a C++ assert() macro (you can tell by reading the error message closely), which is optimized away for production builds of the software, but we're not currently running a production build. We're running a debug build which was created specially for us in response to the first bug report we filed when we started testing XM17. This is a mis-use of assert() statements (and I'll tell them so). It's even possible that they put that assert() statement in to warn themselves of conditions which they would prefer not exist, but which they handle in a benign way, producing displays which work (as they have in all previous versions of XMetaL. That's a discussion we need to have with them.

Can we set a wildcard selector for the Insertion/Deletion elements?

* > Insertion, * > Deletion { display: block; }

Sure, we could do that. Would have the same effect as

Insertion,
Deletion {
  display: block;
}

And that would solve the problem. It may even be that it's our only solution. The display would look like this, though.

We received a production build of XMetaL 17, which appears to eliminate the crashes.

Verified on QA.

Verified on PROD. Thanks!