on further reflection, moderately stable may be a little generous, although, certainly more stable.
I have only used databases converted from Pan 6, as of now. I frequently, maybe half the time, experience crashes upon closing databases. In case it might help, here are the beginning and ending sections of the report I received just now (Itās all Greek to me). I can send the whole report, if you want.
Process: PanoramaX [27866]
Path: /Applications/PanoramaX.app/Contents/MacOS/PanoramaX
Identifier: com.provue.PanoramaX
Version: 0.1.028 (2172)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: PanoramaX [27866]
User ID: 501
Date/Time: 2016-12-16 22:22:57.886 -0800
OS Version: Mac OS X 10.12.1 (16B2555)
Report Version: 12
Anonymous UUID: 44DE4C63-5903-37EA-D7FC-82273A189A35
Sleep/Wake UUID: 8988F098-7FFF-4256-B6EF-2F36919EFE57
Time Awake Since Boot: 23000 seconds
Time Since Wake: 6800 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
VM Regions Near 0x18:
ā>
__TEXT 000000010d9d8000-000000010dc69000 [ 2628K] r-x/rwx SM=COW /Applications/PanoramaX.app/Contents/MacOS/PanoramaX
Application Specific Information:
objc_msgSend() selector name: respondsToSelector:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff97cb5b5d objc_msgSend + 29
1 com.apple.AppKit 0x00007fff811c220d -[NSSplitView _delegateImplementsAutolayoutIncompatibleMethods] + 115
2 com.apple.AppKit 0x00007fff811b49ec -[NSSplitView _splitViewUseConstraintBasedLayout] + 394
3 com.apple.AppKit 0x00007fff811c67c8 -[NSSplitView _needsUpdateConstraintsForProportionalResizing] + 93
4 com.apple.AppKit 0x00007fff811ca2c4 -[NSSplitView nsis_valueOfVariable:didChangeInEngine:] + 69
5 com.apple.Foundation 0x00007fff85012f76 -[NSBlockObservationSink _receiveBox:] + 76
6 com.apple.Foundation 0x00007fff8517bdca -[_NSObserverList _receiveBox:] + 745
7 com.apple.Foundation 0x00007fff8501354f __68-[NSObject(DefaultObservationImplementations) receiveObservedValue:]_block_invoke + 63
8 com.apple.Foundation 0x00007fff850134e2 -[NSObject(DefaultObservationImplementations) receiveObservedValue:] + 185
9 com.apple.Foundation 0x00007fff85124b87 -[_NSISVariableObservable emitValueIfNeeded] + 254
10 com.apple.Foundation 0x00007fff8517eba3 -[NSISEngine
End section below
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 953
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 369566
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=389.8M resident=0K(0%) swapped_out_or_unallocated=389.8M(100%)
Writable regions: Total=1.1G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=1.1G(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Accelerate framework 1792K 13
Activity Tracing 256K 2
CG backing stores 94.6M 9
CG image 4504K 162
CoreAnimation 96.6M 249
CoreUI image data 6620K 46
CoreUI image file 164K 5
Foundation 7372K 13
Image IO 276K 36
Kernel Alloc Once 8K 2
MALLOC 841.5M 266
MALLOC guard page 48K 10
Memory Tag 242 12K 2
Memory Tag 251 96K 5
OpenCL 48K 7
SQLite page cache 64K 2
STACK GUARD 56.0M 13
Stack 13.6M 13
VM_ALLOCATE 376K 44
__DATA 44.0M 403
__GLSLBUILTINS 2588K 2
__IMAGE 528K 2
__LINKEDIT 115.0M 27
__TEXT 274.8M 407
__UNICODE 556K 2
mapped file 137.6M 99
shared memory 16.4M 16
=========== ======= =======
TOTAL 1.7G 1830
Model: MacBookPro11,5, BootROM MBP114.0172.B10, 4 processors, Intel Core i7, 2.5 GHz, 16 GB, SMC 2.30f2
Graphics: AMD Radeon R9 M370X, AMD Radeon R9 M370X, PCIe, 2048 MB
Graphics: Intel Iris Pro, Intel Iris Pro, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453120
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x152), Broadcom BCM43xx 1.0 (7.21.171.47.1a8)
Bluetooth: Version 5.0.1f7, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM1024G, 1 TB
USB Device: USB 3.0 Bus
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1
just trying to keep the pot stired on this issue.
iām now on os 10.12.3 Beta (16D30a) and panx 0.1.029 (2214).
stability has improved substantially, but is still pretty horrible.
i dont know if iām still leading the pack in crashes;[quote=āadmin, post:2, topic:840ā]
@samrutherford has crashed at over 60 times the rate of other users. In fact, during that period you have more than twice as many crashes as all other Panorama X users combined.
[/quote]if not, its because iām still mostly in pan6.
lately the crashes occur when changing windows as well as when closing a window.
i was wondering if jim, or any body else, had any thoughts as to what could be so damned special about my hardware, my os, or the way iām using panorama.
as iāve pointed out before, this is an old mac (macpro5,1, quad-core intel xeon, 2.8 gh), but a new hard drive and new ram.
the only thing possibly unusual about the way i use panorama is that i almost always have a file open full of procedures that other files farcall. c. 170 procs, almost no data, 1.4 mb.
if that could be the problem, i guess most of the procs could be replaced with custom statements and functions, but what a pain in the as that would be, not least because there are probably 1000+ procs that are now farcalls that would have to be rewritten.
any fresh ideas wold be greatly appreciated.
also, iām wondering if the stability issue is getting much attention from provue, or is it just too non-specific to address.
@samrutherford you are not the leader in absolute number of crashes this month, but in terms of crashes per hour of use, you are still by far the leader. I wish I had an immediate answer for you.
Unfortunately, I have no idea why crashes would occur when switching or closing windows. There have been some other scattered reports of crashes when closing windows, this is the first Iāve ever heard of a crash when switching windows. I have never been able to duplicate the crash when closing problem on any computer running any version of the OS (including Sierra). Itās very hard to fix a problem that canāt be duplicated. Someone sent a database a while ago that they claimed crashed almost every time when closing a window, on my computers I could never get it to crash even once, and I tried pretty hard.
always have a file open full of procedures
All Panorama users have files open full of procedures ā Panoramaās libraries. So that is not the problem.
could be replaced with custom statements
A custom statement is just syntax sugar for a farcall. Under the hood, Panorama is actually doing a farcall every time a custom statement is used. You can use farcall to invoke a custom statement.
Sam, I too have experienced many crashes with Panorama 6. It seemed like it was only me and after many, many days, weeks, months of it happening, I was able to identify a sequence of steps that would be taken just prior to Panorama unexpectedly quitting. I then used my favorite Snapz Pro X to create a movie of the sequence of events just prior to Panorama quitting. I submitted the movie to Jim, and he was able to recognize the interaction of my browser and Panorama and how when I did a very specific series of steps, that yes, Panorama would quit. Jim suggested that I not do that series of steps so Panorama wouldnāt quit. (Kinda felt like 'I was holding my phone wrong 
) but the bottom line was that it was an essentially very rare (to others) but consistent to me, series of steps that caused the problem. When I learned via Jimās assistance that I could do what I needed to do, but just clicking āhereā instead of āthereā and then clicking āhereā, that I could work without the crashes. I was a much happier camper after I learned to alter my process with an extra āclickā on a Panorama form, and the crashes stopped happening to me.
The bottom line is that some crashes are unique to how we each do our particular process. See if you can find a pattern to them, and then share that experience with Jim via a movie and you may find a way around the problem with having given Jim an insight to your particular need which he will then fix as that is where we are at with Panorama X. We are looking for those holes that are not easily found in daily use by all others.
Robert Ameeti
1 Like
Sam, you are suffering so many crashes ā and you are using BETA system software. So why donāt you update to the release version of macOS 10.12.3 (build 16D32)? Itās out since monday. I am using it and have no issues at all.
thanks robert, jim, and klm.
re my os, iāve been waaaaaay better off with the various 10.12.2 and 10.12.3 betas than with the previous public release os versions. but iām glad to know thereās a public release now and iāll give it a try.
Just for the record, I was using Pan X an hour ago but havenāt touched it since then. It lives on a different desktop than the one I mostly use. Just now got a Pan X crash report in the desktop I was using. How does it crash when it is just sitting idle?
Iām on El Capitan ver 10.11.6.
I would think the answer is, āIt doesnātā. Something else is causing the problem - and your earlier problems. Itās probably time to do a clean install.
does updating the software whenever a new version comes out constitute a āclean installā? Iāve had these problems with every version one way or another.
No other software Iāve ever used crashes at idle, at simply clicking someplace, trying to close a window, etc. If itās this touchy, I shudder to think how itās going to fly when it goes public.
A clean install involves backing up ALL your stuff, wiping the hard drive and installing an OS from scratch. But before you take that radical step, you might try storing your files in a different folder - maybe your other desktop isnāt a good place. See if it happens again (I assume this was the first occurrence?).
Also, bear in mind that nobody else has ever reported this problem - so far itās unique to your set-up. Panorama really, truly isnāt āthis touchyā - not by a long shot. I think you need to look for the problem closer to home Scott.
Actually it does do things when you are not using it. And yes, it has happened to others including myself.
Robert Ameeti
Maybe it is not a brilliant idea to leave a RAM-based database application unattended open, idle for a long time, while you know that macOS is trying to compress RAM occupied by idling apps.
That would be a very serious bug in macOS. I routinely leave both Panorama 6 and Panorama X open for days, sometimes weeks. Other applications also. As far as that goes, I would be more worried about cosmic rays.
Over the past four months, usage of Panorama has been fairly flat (up about 3%). Crashes, however, are down 25%, and they have gone down in each month. Iām certainly hoping that is because new releases have come out with additional bug fixes. There will be more fixes dropping soon.
I do think there is something āextraā going on on a few user;s computers. @staylor246, I donāt suppose you kept the crash log from your crash that happened while the program was āidleā? One crash log usually isnāt all that informative, but eventually hopefully a pattern will emerge.
Thank you Robert - I stand corrected.
Well, I never throw anything away 
(ask my wife). I have all of my crash logs, for everything that ever crashed, since early January. I gather they scroll off after a while. Do you want to see it? I canāt make any sense of it. I can save it somewhere and amass any other āidleā crash reports there if there are any. Tell me what I should do.
There may well be āsomething āextraā going onā with my computer, but I never experience anything more serious than slow performance sometimes with any other apps. Jim, do the crash reports you see identify the source, or just numbers of crashes?
If by source, you mean the source within the program, then no. They just say that a crash happened at a certain time ā which actually is the time you next launched Panorama, not the time of the crash.
I have all of my crash logs, for everything that ever crashed, since early January. I gather they scroll off after a while. Do you want to see it? I canāt make any sense of it.
Yes, I would like to see it. Itās extremely rare that they provide enough information to actually fix a bug, but they can provide useful information that sometimes helps in combination with other information.
No, by āsourceā I meant does it identify who had the crashes, so you can detect people with problems like mine. Probably not.
I am emailing you the crash log from the idle crash, and Iāll include the one before it on the same day in case that sheds any light.
You said the report tells you āthe time you next launched Panorama, not the time of the crashā. Is that regardless of whether you clicked the āReopenā button on the crash report, or just started it fresh from the icon in the dock? I usually donāt click āreopenā and probably a certain number of others donāt either.
Yes, it does identify the name of the user that has the crash.
You said the report tells you āthe time you next launched Panorama, not the time of the crashā. Is that regardless of whether you clicked the āReopenā button on the crash report, or just started it fresh from the icon in the dock?
It doesnāt matter which way you re-open it. If Panorama crashes ā itās crashed, so it canāt send anything! But the next time it launches, it notices that it didnāt quit normally last time, indicating a crash. So thatās when it sends the notice that a crash occured.
I clarified this with Robert, and he experienced crashes at idle with Panorama 6, not Panorama X. So so far, Scott is the only person to report a crash at idle. Doesnāt mean there might not be something wrong with Panorama causing the problem, of course.
And since Mavericks, thereās been an App Nap added to the OS that essentially sleeps idle applications. You might try Get Info on Panorama and check Prevent App Nap to see if that changes anything.
As the Activity Monitor demonstrates, there are all sorts of other things going on all the time. Who knows when one steps on the toes of another?