As a first step, please upgrade to version 4.4 and see if that fixes your issue.

Yes, the issue happen both 4.3 and 4.4

Yes, the issue happen both 4.3 and 4.4

What do the three windows contain, are they all registers or do some have reports open in them.

Does the number of windows matter, does just two windows behave ?

Can you add the full crash report, I do not have a mac but may help identify problem.

Hi, 
I tested with empty windows
It also crashed.
(New file, add new 2 empty windows and quit, crashed)

I tested on older Mac (Intel chipset)
It also reproducible

Here is full log

https://gist.github.com/chaintng/d491645b70a9ebbf6564280cd7176dae

Here's the top of the stack with debugging symbols:
  * frame #0: 0x0000000101eba995 libgobject-2.0.0.dylib`g_type_check_instance_cast(type_instance=0x000000010c842310, iface_type=4486990448) at gtype.c:4060:55 [opt]
    frame #1: 0x0000000100f92611 libgnc-gnome-utils.dylib`gnc_main_window_close_page(page=0x000000010b9d3130) at gnc-main-window.c:3330:33
    frame #2: 0x0000000100c82a72 libgnc-gnome.dylib`gnc_plugin_page_account_tree_close_cb(user_data=0x000000010b9d3130) at gnc-plugin-page-account-tree.c:703:5
    frame #3: 0x0000000100f6ee35 libgnc-gnome-utils.dylib`gnc_close_gui_component(component_id=1) at gnc-component-manager.c:781:9
    frame #4: 0x0000000100f6efb0 libgnc-gnome-utils.dylib`gnc_close_gui_component_by_session(session=0x0000000153b0d7c0) at gnc-component-manager.c:837:9
    frame #5: 0x0000000100f83ba6 libgnc-gnome-utils.dylib`gnc_file_quit at gnc-file.c:1726:5

And the reason for the crash:
(lldb) p *window
(GncMainWindow) $2 = {
  gtk_window = {
    bin = {
      container = {
        widget = {
          parent_instance = {
            g_type_instance = {
              g_class = 0xaaaaaaaaaaaaaaaa
            }
            ref_count = 2863311530
            qdata = 0xaaaaaaaaaaaaaaaa
          }
          priv = 0xaaaaaaaaaaaaaaaa
        }
        priv = 0xaaaaaaaaaaaaaaaa
      }
      priv = 0xaaaaaaaaaaaaaaaa
    }
    priv = 0xaaaaaaaaaaaaaaaa
  }
  ui_merge = 0xaaaaaaaaaaaaaaaa
  window_quitting = -1431655766
  just_plugin_prefs = -1431655766
}

So the window has already been freed, the trick is to figure out where. Note that this doesn't happen on Linux or Windows because distros build GLib with debugging disabled and I build it with minimal debugging.

@Bob, he's creating truly empty windows with Windows>New Window.

Well, that was easy. The first free was exactly 2 lines above.

Fixed for 4.5, thanks for the report.

@Bob, it appears that in this case we still leak any empty windows. That's probably not a big deal given that we're shutting down but it's still not ideal. If you have some free cycles you might look into checking that all windows on the active window list are freed at shutdown.

I am looking at this with my Linux VM. What I have found with the code as was, all seems to work OK with two windows of any sort. If I do as the reporter, one with the account tree and two or more other windows empty or not I get a failure on the second gtk_widget_destroy.

I am also seeing that one window is not calling gnc_window_destroy.

Will investigate...

Does the window that doesn't have gtk_window_destroy called on it have a page?

*** Bug 798137 has been marked as a duplicate of this bug. ***