PX crashing on closing procedure window in Sierra BETA


#1

PX crashes almost every time I try to close the topmost procedure window. If I open another procedure window on top of the one I was working in, and close the window while it’s in the background, it usually works. I can then close the new top window without crashing PX. Needless to say this is very frustrating… I’ve taken to manually saving the database before I close any windows. It reminds me of Panorama 5 which would also crash frequently while I was editing forms.


#2

This may be something I have seen, but it is often difficult to figure out the exact sequence that causes the crash.


#3

There is definitely something going on for you – I checked the logs and you have by far the most crashes in the last month of any user – in fact you have experienced over a quarter of ALL Panorama X crashes in the last 30 days, so you are encountering crashes about 20-25 times more frequently than the typical user. That has to be super frustrating. (Privacy note – the only information sent to ProVUE is the time and date of each crash (actually the next restart after the crash), the version of Panorama, and the version of the OS, there is no additional information at all.)

So the question is why is this happening – is it something about your system, or perhaps something in one or more of your databases.

I can say that I’ve literally closed thousands or procedure windows with never a crash, maybe tens of thousands. (Full disclosure, I am not running the Sierra beta. Hmm, on further investigation it appears that you are the only person running Panorama X on macOS 10.12.1, and all of your crashes are on that version and your crashes are over 35% of all crashes reported on 10.12 systems. So perhaps this problem is related to the fact that you are running a Sierra beta version.)

One further thought – is there a particular window that is becoming active when you close the procedure window? perhaps a particular form window? Maybe it is not the procedure window closing, but the form window becoming active that is causing the problem? Is this happening with one particular database and/or one particular form?


#4

I am wondering if more metadata collection at time of crash might be handy. File names that were encrypted and only decipherable by the user to acquire the real name? File sizes? Record counts? Number of forms? Number of procedures? Encrypted name of last run procedure?

Robert Ameeti


#5

It’s the same database every time… my fabulous new Gradebook X. The form that is open at the time varies. I click the close button on the top procedure window and (quite often) there’s a crash. If I open another procedure window on top, I can (usually) close the procedure windows behind it with no problem, and (usually) I can close the new top window then without issue.

I think it might be a memory management problem so I am closing apps that are usually running in the background. I’ll get back to you with the results.

I’ve also reported the crashes to Apple, of course.

It’s probably good (for us all) that I’m running the Sierra BETA because it’ll give us a chance to head off any issues between PX and the next update of Sierra before it screws up everyone running the current OS. I consider it pre-emptive beta-testing for all concerned.

:sunglasses:


#6

So I ran into the same problem with the release version of Sierra, as I noted elsewhere.


#7

Shutting down all the programs running in the background seemed to help for awhile, but within 30 minutes, it was back to it’s old tricks, crashing when I closed a top window. It’s as if PX just expanded the memory it was controlling until it ran up against the only program still running, Mail, and the crashing started again. You’d think that 8GB would be enough… I checked “Memory Usage” in the main menu, and it said PX was using 8.43 KB, which seems to be unaffected by how many windows are open…

On a separate note, using one of my procedures to delete a selected record seems to result in deleting not the selected record but the following one. From the Data Sheet, selecting a record and clicking the Delete button works just fine. But it wasn’t working right when I used procedures… I used a procedure to select a student record. Then I ran a procedure to delete the record, but by then, it seems like PX had lost the connection to the selected record, and deleted the next record in line.

I used my procedure to select a student record. I checked the Data Sheet to make sure the correct record was selected. Then I clicked the button on the student roster form that ran the procedure to delete the record. It deleted the next record in line instead… I managed to fix it by re-selecting the record in the line immediately before the “deleterecord” command. Then PX deleted the correct record.

That’s just weird… just one more thing that doesn’t quite work the way I expect.

You remember that I’m doing this to help keep my mind sharp in my old age… bwahahahahahahahaha!!! What FUN!


#8

You must mean 8.43 MB. There’s no way any OS X application could be using less than a megabyte.

Actually I would be surprised if Panorama’s memory usage was as low as 8 MB. Right now my computer has about 70 processes using > 8 MB. My copy of Panorama X is using about 200 MB.

I checked “Memory Usage” in the main menu

Oh wait, you mean you checked this in Panorama itself. I though you had checked this in the Activity Monitor app. Panorama’s memory usage window isn’t going to show anything particularly useful as far as memory pressure on the application. It only shows the size of the data being used, it doesn’t show memory used for forms, procedures, windows, menus, or anything else.

until it ran up against the only program still running, Mail

If it makes any difference what other applications are running, your system has serious problems. OS X and modern Intel processors completely isolate applications from each other. We’re a long way from the bad old MacOS 9 days.

You might check to see if you can find a crash report for Panorama after one of these crashes. That might be useful in tracking down what the actual problem is (though it usually isn’t that useful, unfortunately).

What does that mean? Did you use the find statement? If this is happening in a procedure, then there is some code involved. It would be better to post the actual code rather than giving an anthropomorphized description of what is happening, then perhaps myself or someone else here can see what is going wrong.

It doesn’t have a “connection” to the selected record – that implies some sort of separation.


#9

What value is the Memory Usage in Pano X?

Robert Ameeti


#10

You’re right… I used PX to check memory usage… Activity Monitor says 423.4 MB Memory and 193 MB Compressed Mem… with just one form open. With one form and four procedures it goes up to 752.3 MB.

Sandboxing… right. That’s supposed to work well and be damn near foolproof. I wonder why PX keeps crashing. Sometimes it just freezes, and I have to force quit.

I’ll see what I can do about a crash report… usually it just crashes, and I get a system notification that says it quit unexpectedly. I’ll see if I can tease out more info…


#11

It really doesn’t have any practical use. Unlike Panorama 6, all memory allocation is automatic, and there are 64 bits available, so that dialog is basically ornamental. Fortunately I didn’t spend much time implementing it – in fact it is actually a Panorama form!

For a bit of context, on my system the typical Safari window takes up 300 - 900 MB. That’s per window.

Also notice that Activity Monitor shows both Memory and Real Memory columns. Right now my copy of Panorama X shows that it is using 662MB, but only 155MB of real memory.


#12

Personally, if something has no value, I’d remove it to keep things significant.

Then too, if it could show the percentage or amounts of memory that the Forms consumed (and even on a form by form basis), along with the same for procedures, and then data, that could be useful.

I’ve had occasions to want to take a mini version of an app I’ve created and after deleting 95% of what I’d considered a lot of data, my file size had shrunk only 5%. I ultimately learned that my forms were consuming over 80% of my file size. I then concentrated on that part eliminating many obsolete forms that I no longer needed and was able to effectively trim the file size done. This kind of stuff is not always obvious but sometimes significantly informative.

Robert Ameeti


#13

For the record, according to the Memory Usage Wizard, the database that I have open which has been crashing Panorama X on closing a procedure shows that it is using 12 bytes of data-one empty record. Activity Monitor says Panorama X is using 73 MB.


#14

LOL.

I just looked at one of my tables in my frequently used database. That table has 7,200 records with 155 fields. It consumes 6 MB of memory. Then I take a peek at my forms. My most commonly used form which is pretty busy is 3.1 MB all by itself. Removing data or fields is not what is going to be effective to thin this table down in size. The 112 procedures in that table consume only 357K. No reason to pare those down either.

These kind of facts can be helpful.

There was some talk a while back about separating the data from the forms and procedures. This was going to be helpful so that we could upload a minimal amount of ‘stuff’ when we make a minor change to a server based Panorama database. Is that still in the plan? I always hate uploading 120 MB of file data when all I need is to alter a typo on a form.

Robert Ameeti


#15

If you look inside a .pandb package you’ll see that the data, forms and procedures are already stored separately.

Unfortunately, it can’t. Believe me, I would like to have reported this, but as far as I can tell there is no reasonable way to find out the memory footprint of a hierarchy of Objective-C objects, which is what forms and procedures are.

The memory usage reported by Activity Monitor includes a lot more than the open databases. It also includes the application’s code, the runtime stack, all kinds of system allocations, memory for menus, windows, and other ui components, etc.

Earlier in this thread, @sensiblemike speculated that his crashes might have something to do with running out of memory or some sort of memory allocation problem. I think that is very unlikely, and I should have said so right away. This discussion has I’m sure been interesting to some, but unfortunately I don’t think it illuminates any particular crashing problem in any real way.