Print One Record crash

This happens consistently for me:
Made a new database
Made some fields
Made a new form, pasted a jpg into it
Added some text editors atop the jpg
Populated a couple records in the data sheet
Added a data tile to the form so it prints
Selected ‘Print One Record…’
Used the PDF menu to send the PDF to mail

Panorama sends the form to mail as expected, but while I am in Mail, Panorama crashes in the background.

It crashes if I select Print one Record in the File menu, it does NOT crash if I type cmd-p and make a pdf that way. It doesn’t seem to matter if the active record is the first or last record, it crashes either way. Using Print One Record, it happens every single time.

I have logging on but since i am not running a procedure, there’s not much to log, this is what’s in the terminal:

zsh: segmentation fault /Applications/PanoramaX.app/Contents/MacOS/PanoramaX

Saving session…

…copying shared history…

…saving history…truncating history files…

…completed.

[Process completed]

And here is the last part of the log- I could post more but it’s really long!

+[AssignStatement setValue:value:] goodAssign: TRUE (variables)
-[FunctionResultStatement run] Terminal
-[ReturnStatement run]
-[ProcedureStack returnFromProcedure] stackCount: 1
-[ProcedureStack returnFromProcedure] No running frame, we are stopping.
-[ProcedureStack returnFromProcedure] stackCount: 0
+[AssignStatement setVariable:value:pool:] setVariable: appName pool: 3
+[AssignStatement setVariable:value:pool:] Variable assigned.
+[AssignStatement destinationIsField:] fieldNumber: 9223372036854775807
+[AssignStatement setValue:value:] setValue: appName ===============================
+[AssignStatement setValue:value:] goodAssign: TRUE (variables)
+[AssignStatement destinationIsField:] fieldNumber: 9223372036854775807
+[AssignStatement setValue:value:] setValue: appName ===============================
+[AssignStatement setValue:value:] goodAssign: TRUE (variables)
-[FunctionResultStatement run] Terminal
-[ReturnStatement run]
-[ProcedureStack returnFromProcedure] stackCount: 1
-[ProcedureStack returnFromProcedure] No running frame, we are stopping.
-[ProcedureStack returnFromProcedure] stackCount: 0
+[AssignStatement setVariable:value:pool:] setVariable: zlogging pool: 3
+[AssignStatement setVariable:value:pool:] Variable assigned.
+[AssignStatement setVariable:value:pool:] setVariable: logProcedures pool: 3
+[AssignStatement setVariable:value:pool:] Variable assigned.
-[FunctionResultStatement run] -1
-[ReturnStatement run]
-[ProcedureStack returnFromProcedure] stackCount: 1
-[ProcedureStack returnFromProcedure] No running frame, we are stopping.
-[ProcedureStack returnFromProcedure] stackCount: 0

Having seen no other reports about this I was wondering if it had to do with my setup. I can confirm that it happens though with Print One Record. It always gets the printing done, then a moment later Panorama crashes. I’ve also had it occur when printing reports if I choose to open or save them as PDF.

I do need to run some tests to determine all of the circumstances that do or don’t work so at this point my information is suspect on accuracy.

An unproven theory… if I quickly do something else with Panorama, I can avoid the crash.

2 Likes

A few weeks after b25 was released, I started noticing a mysterious crash in the crash reports. The crash report indicated that no Panorama code was involved in the crash, only Apple code. The crash report indicates that the crash is occurring in an Apple feature that Panorama does not use, and never has used. I’ve never been able to duplicate this crash on any of my computers, but it is coming up quite frequently in the crash reports in the past 3 months. Based on the crash reports, several dozen users have experienced this crash.

Since I first noticed this in the crash reports, I have received a handful of reports of crashes from users that I was able to match up with a crash report. So far every case I know of has involved printing – specifically, the printing works, but then Panorama crashes immediately afterward. I have verified that this crash report pattern has shown up for both @watts and @JamesCook, so I’m pretty sure the problems they’ve experienced have been part of this mysterious pattern. They both fingered Print One Record, but I’m pretty sure other users have reported this happening with a regular Print operation. It seems unlikely that only Print One Record would be involved, because in all cases I have heard of the print operation itself succeeds, and the crash happens afterward. Once the print operation is finished Panorama doesn’t even keep any record that print one record was used instead of print. Also keep in mind what I stated earlier – the crash report shows no trace of any Panorama code running (including any code for printing), only Apple code. I’m wondering if the Apple code is doing some kind of cleanup after printing (though the crash report doesn’t really give any indication of what the Apple code is trying to do.)

This crash mysteriously started after b25 was released. It did not occur at all in b24 or any earlier version. There was no change to Panorama’s printing code between b24 and b25. However, there was a big overall change between b24 and b25. The b24 version was generated using Xcode 8 on an Intel computer, the b25 version was generated using Xcode 12 on an M1 computer. Each time a project is transferred into a new version of Xcode, Xcode fiddles with the project settings. So I’m wondering if changing the Xcode versions has caused this.

I guess another clue is that this problem apparently only occurs on Big Sur and Monterey. There are no crash reports for this problem with Catalina or earlier systems.

Since January I’ve spent a lot of time on this issue, but unfortunately I haven’t made any progress. If this problem persists after b26 is released, I will probably have to see if I can get any help from Apple engineers, maybe at WWDC.

1 Like

I’ve also had numerous crashes after printing in recent weeks with macOS 12.2.1. To confirm, I just printed the first page of a 5-page procedure, using the Page: 1 to 1 option in the print dialog. This crashed Panorama b25. Then tested printing a single paged procedure, which also crashed Panorama. Then tested printing all pages of a 2-page procedure, which also crashed Panorama.

Your three crashes all showed up in the crash report database, at 8:11, 8:13 and 8:17 PM (I think that is California time). Definitely the same mysterious crash pattern, with only Apple code listed in the crash report.

Based on your report, I just tried printing a procedure. It worked perfectly, no crash. I’m running macOS 11.6 on an M1. I found at least one user that had this crash with the exact same OS build I am running (Build 20G165). Of course, I am running a running a newer, Apple Silicon native version of Panorama on my computer.

Interesting update – I just tried printing a procedure using b25, and it crashed first time! So maybe I’ve fixed this problem in the process of making an Apple Silicon native version (there have been a lot of changes since b25). Or maybe the crash doesn’t happen when running a debug version of Panorama, now there’s an unhappy thought.

Further update – I can reliably crash b25 on my computer by printing a procedure. But b26 doesn’t crash. Same database, same procedure. I just tried it with a non-debug version of b26 and it worked fine. So maybe this problem is fixed? :crossed_fingers:Or rather will be fixed when b26 is released. That would definitely be great.

(Before you ask, I don’t feel that b26 is ready to ship yet. For example, it has not yet been tested at all on an Intel computer, or on any version of macOS older than Big Sur.)

Well, this sounds like good news for me, I have a 16" M1 Max 64g which is supposed to arrive tomorrow.

(That said, I’m on an island with no postal service and I’ve been told ‘tomorrow’ every day for the last two weeks. On friday a courier delivered a box of battery chargers to my office, claiming it was my computer… not good!)

Anyway, thank you for the background on this issue - I don’t do a lot of printing (yet) so i can survive this one.

cw

Let’s hope you fixed it - whether you intended to or not. :wink:

Just in case, here’s a possibly helpful clue. Over and over I can cancel once the Print Dialog comes up with no issue. Choose Print, Preview or PDF and an instant later Panorama crashes.

If I immediately activate a Panorama window after choosing Print, the crash is avoided.

This is on Monterey with both Intel and M1 processors.

1 Like

Interesting. I wonder if when you print Apple is creating a temporary invisible window.

Remember when Crocodile Dundee said “that’s not a knife, THIS is a knife”? Well that wasn’t background, THIS is background! Enjoy.

I have had this issue as well ( M1 and Big Sur). Today I discovered if I pause the printer prior to printing it seems to pre-empt the crash. I can then resume the printer a few seconds later and no crash occurs. At least a helpful work around until the next update.

What does “pause the printer” mean? Is this something you do in the Printer application, or on the printer itself?

This has to be one of the weirdest bugs I’ve ever encountered.

When you print, the printer queue shows up in the dock, or you can open it in the preference pane. It can be opened, and one of the options is to pause the printer.

Yes, but I didn’t want to make any assumptions about what @KevinShantz was describing. Been burned too many times by that sort of assumption.

As Bruce indicated, what I meant was opening the print queue window for the printer and clicking on the pause button, prior to issuing the Print command in Panorama. See screen shot.

Kevin
Screen Shot 2022-04-11 at 10.03.13 AM

Not to be pedantic, but the arrow is pointing at the “kill” button, i assume you meant the one to the right of the one the arrow is pointing at…?

:slight_smile:
csw

Very observant! :face_with_raised_eyebrow:
Actually it should be pointing at the button above it, the circle with the triangle which is the button for the printer as a whole, in the “paused” state. ie you pause the printer before sending the document.

Not wanting to be left out of the party, I can now affirm that the crash happens to me after a standard Print with a Form being the active window. (I do only have 1 record selected.) The print happens, then Panorama is returned as the focused application, then seconds later crashes.
If I pause the printer’s app before printing, Panorama does spool the document to the printer, and then sits happily. I can then go to the printer’s app, un-pause the printer and print the document. I manually set focus to Panorama and all continues to be fine.
macOS 12.3.1

If I print to PDF (Save as PDF) from my printer dialog, Panorama does not crash. Only when I print to my physical device.

FYI, while running Monterey, the following occurs:

Preview One Record: works, no crash
Print One Record → Save as PDF: works, no crash
Print One Record → Print: prints the records, and Pan X crashes
Print One Record → Open in Preview: does not work, Pan X crashes

This is true across multiple Pan X databases.

Jim, how might one get Pan X printing right now, on a Mac Mini (2020) running an Apple chip?

Reverting to Catalina will not work for me, as my Mac Mini is from 2020, and unable to accept Catalina (macOS Catalina is compatible with these computers - Apple Support).

The working answer that most have found will work is to manually pause the ‘printer’, print the job to the printers queue, then after Panorama is done being involved, manually unpause the printer to release the print job to the printer.