Problems while exiting root .q with canvas (3)

[bozzochet]

Hi,

I described my problem here:

Problems while exiting root .q with canvas (2)

Ciao, I have the very same same problem as described here: https://root-forum.cern.ch/t/problems-while-exiting-root-q-with-canvas/36167/3 If I call a function that creates a TCanvas, and I close this canvas, I get a root crash when I “.q” ROOT: root [0] .L Analysis/DAQ_light.C+ Info in <TMacOSXSystem::ACLiC>: creating shared library /Volumes/amssw/duranti/POXsimu_install/./Analysis/DAQ_light_C.so root [1] DAQ() root [2] .q 2019-12-09 10:50:31.535 root.exe[27017:4477869] Fatal error: requeste…

but now the post is closed and so I cannot reply anymore.

I just recompiled ROOT, this time 6.20.4, after having removed any .rootlogon.C and any reference to old root versions from the .bashrc (i.e. from $PATH, $LD_LIBRARY_PATH and $LIBRARY_PATH) and the problems is still present: if I have N canvases open and I close some of them, when exiting from ROOT I have a crash. If I close all the canvases or no canvases at all, there’s no crash.

Any idea? Where also my environment could be wrong?

Matteo

---

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.20.4
Platform: MacOsX 10.14.6
Compiler: Apple clang version 11.0.0 (clang-1100.0.33.8)

---

[pcanal]

What does runnning the failing example under valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp ..... reports?

[bozzochet]

Sorry, I’m not an expert of valgrind, since I develop mainly on OsX (and so Tools): do I have to run the ROOT cling under valgrind?

Thanks,
Matteo

[pcanal]

Yes, you would do:

valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe

and then enter the command as usual.

[bozzochet]

Hi,

I’m not even able to run valgrind:

bozzo@MacBook-Pro:BDTRICHEle> valgrind --suppressions=$ROOTSYS/etc/valgrind-root.supp root.exe &> log.txt
root [0] Segmentation fault: 11

even if root, alone, seems ok:

bozzo@MacBook-Pro:BDTRICHEle> root
Style set
root [0] .q
bozzo@MacBook-Pro:BDTRICHEle> 

Here’s in attachment, however, the log:

log.txt (522.2 KB)

Any hint on my problem?

Thanks,
Matteo

[pcanal]

so valgrind is not working well on MacOS …

Next is to run in the debugger. You will need a debug build of ROOT first. Then do

lldb -- root.exe [what_ever_args]
lldb> process launch -t

and investigate the failure.

[bozzochet]

Hi,

so, I managed to recompile the very same ROOT with -DCMAKE_BUILD_TYPE="Debug".

On the “main” terminal I obtain:

bozzo@MacBook-Pro:BDTRICHEle> lldb -- root.exe
(lldb) target create "root.exe"
Current executable set to 'root.exe' (x86_64).
(lldb) process launch -t
Process 35810 launched: '/amssw/duranti/root-6.20.04_debug_install/bin/root.exe' (x86_64)
Process 35810 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff66e7b2c2 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff66e7b2c2 <+10>: jae    0x7fff66e7b2cc            ; <+20>
    0x7fff66e7b2c4 <+12>: movq   %rax, %rdi
    0x7fff66e7b2c7 <+15>: jmp    0x7fff66e75453            ; cerror_nocancel
    0x7fff66e7b2cc <+20>: retq   
Target 0: (root.exe) stopped.
(lldb)  

while on the terminal (i.e. ROOT session) opened by lldb:

bozzo@MacBook-Pro:~> /bin/bash -c 'arch -arch x86_64 '/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/darwin-debug' --unix-socket=/tmp/xYJdpx --arch=x86_64 --working-dir '/Volumes/amssw/duranti/myAMSRoot/amsacommonsw-code/BDTRICHEle' --disable-aslr --env='OS_ACTIVITY_DT_MODE=enable' --  '/amssw/duranti/root-6.20.04_debug_install/bin/root.exe' ; echo Process exited with status $?';exit

Launching: '/amssw/duranti/root-6.20.04_debug_install/bin/root.exe'
Working directory: '/Volumes/amssw/duranti/myAMSRoot/amsacommonsw-code/BDTRICHEle'
1 arguments:
argv[0] = '/amssw/duranti/root-6.20.04_debug_install/bin/root.exe'
   ------------------------------------------------------------------
  | Welcome to ROOT 6.20/04                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for macosx64 on Apr 01 2020, 08:28:48                      |
  | From tags/v6-20-04@v6-20-04                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------

Style set
root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas c 
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] .q
2020-06-09 09:16:13.890204+0200 root.exe[35810:3358289] Fatal error: requested non-existing drawable 99
2020-06-09 09:16:13.890273+0200 root.exe[35810:3358289] This window not found among allocated/deleted drawables
Assertion failed: (winIter != fDrawables.end() && "GetWindow, non-existing window requested"), function GetWindow, file /Volumes/CaseSensitive2/amssw_cold/duranti/root-6.20.04/graf2d/cocoa/src/CocoaPrivate.mm, line 127.

I don’t know it this can help and I think I always forgot to mention: if instead of closing one of the two canvases with the “x” but I send a c.Close(), the crash doesn’t happen…

Do you find any hint?

Thanks,
Matteo

[eguiraud]

Hi,
if things are ok if you at teardown, call Close before you quit the prompt, this points to a problem with lifetime of objects at ROOT teardown. I am compiling v6.20/04 with debug symbols on linux to check (it would be weird if Mac had this bug and not Linux, it’s more probable that it happens to be visible on Mac but not on Linux).

In case I won’t find anything, just to have another datapoint, since it should be simple to acquire: if you install ROOT via homebrew, does it still show this issue? (it should be just brew install root if you have homebrew installed).

Cheers,
Enrico

[bozzochet]

Ciao,

• I think I mentioned in one of the two “previous” (now closed) posts: I have other colleagues, with the same MacOsX version and compiling the same version of ROOT (at that time was the 6.18), not having the same issue

• I’ll try with the brew ROOT

Thanks,
Matteo

[eguiraud]

If it’s a use after delete, it may or may not result in visible errors depending on the exact position of objects in memory, which in turn depends on environment, compilation options, etc…

I am afraid that valgrind does not see memory access errors though:

~/R/build_v6-20-04 ~/Tools/valgrind-3.15.0/bin/valgrind --suppressions=etc/valgrind-root.supp root.exe
==25309== Memcheck, a memory error detector
==25309== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25309== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==25309== Command: root.exe
==25309==
   ------------------------------------------------------------------
  | Welcome to ROOT 6.20/04                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Jun 09 2020, 07:48:41                 |
  | From tags/v6-20-04@v6-20-04                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------

root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas c
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] .q
==25309==
==25309== HEAP SUMMARY:
==25309==     in use at exit: 26,214,113 bytes in 28,735 blocks
==25309==   total heap usage: 107,041 allocs, 78,306 frees, 79,520,017 bytes allocated
==25309==
==25309== LEAK SUMMARY:
==25309==    definitely lost: 16 bytes in 1 blocks
==25309==    indirectly lost: 0 bytes in 0 blocks
==25309==      possibly lost: 10,210,621 bytes in 7,679 blocks
==25309==    still reachable: 582,618 bytes in 4,217 blocks
==25309==                       of which reachable via heuristic:
==25309==                         stdstring          : 40 bytes in 1 blocks
==25309==                         multipleinheritance: 19,440 bytes in 11 blocks
==25309==         suppressed: 15,420,858 bytes in 16,838 blocks
==25309== Rerun with --leak-check=full to see details of leaked memory
==25309==
==25309== For lists of detected and suppressed errors, rerun with: -s
==25309== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 213 from 6)

It’s also suspicious that valgrind segfaults and lldb dies on startup on your machine… at least in first approximation, it would point to some issue in your environment, but I’m afraid I can’t say what exactly.

Sorry I can’t be of more help! It seems impossible for us to reproduce the problem or even debug it from a distance with your help

[bozzochet]

Ciao,

no no, lldb is not dying on startup: it opens a new terminal window and “waits” correctly. When I open the two canvases in ROOT, then I close (with the “x”) one of the two and I close ROOT, then lldb comes back to the “command prompt” and then I close it:

(lldb) quit
Quitting LLDB will kill one or more processes. Do you really want to proceed: [Y/n] Y

Matteo

[bozzochet]

Ciao,

same issue with the brew ROOT:

bozzo@MacBook-Pro:~> . /usr/local/bin/thisroot.sh
bozzo@MacBook-Pro:~> which root
/usr/local/Cellar/root/6.20.04_2/bin/root
bozzo@MacBook-Pro:~> root
Style set
root [0] TCanvas c 
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas a
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] .q
2020-06-09 10:48:38.431 root.exe[46492:3452512] Fatal error: requested non-existing drawable 99
2020-06-09 10:48:38.431 root.exe[46492:3452512] This window not found among allocated/deleted drawables

 *** Break *** segmentation violation
[/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)
[<unknown binary>] (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libGpad.so] TCanvas::SetDoubleBuffer(int) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libGpad.so] TCanvas::Close(char const*) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libGpad.so] TCanvas::Destructor() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libGpad.so] TCanvas::~TCanvas() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCling.so] cling::IncrementalExecutor::runAndRemoveStaticDestructors(cling::Transaction*) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCling.so] cling::Interpreter::runAndRemoveStaticDestructors() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCling.so] TCling::ResetGlobals() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TROOT::EndOfProcessCleanups() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TUnixSystem::Exit(int, bool) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TApplication::Terminate(int) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TApplication::ProcessLine(char const*, bool, int*) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libRint.so] TRint::ProcessLineNr(char const*, char const*, int*) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libRint.so] TRint::HandleTermInput() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TUnixSystem::CheckDescriptors() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TMacOSXSystem::DispatchOneEvent(bool) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TSystem::InnerLoop() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TSystem::Run() (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libCore.so] TApplication::Run(bool) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/lib/root/libRint.so] TRint::Run(bool) (no debug info)
[/usr/local/Cellar/root/6.20.04_2/bin/root.exe] main (no debug info)
[/usr/lib/system/libdyld.dylib] start (no debug info)
Root > .q

nice test. I never thought about doing this.

However I was already convinced that is my environment, the problem is that is really almost impossible to understand where…

Thanks,
Matteo

[pcanal]

In lldb at the point of the crash, what does bt shows?
How are you using a Cocoa or an X11 build of ROOT?
If you are using an X11 build, what X11 server software are you using?

[bozzochet]

Hi,

• almost nothing:

(lldb) target create "root.exe"
Current executable set to 'root.exe' (x86_64).
(lldb) process launch -t
Process 63638 launched: '/amssw/duranti/root-6.20.04_debug_install/bin/root.exe' (x86_64)
Process 63638 exited with status = 0 (0x00000000) 
(lldb) bt
error: invalid thread
(lldb)

• I didn’t specify… Seems “cocoa”:

bozzo@MacBook-Pro:BDTRICHEle> root-config --features

cxx14 asimage builtin_afterimage builtin_clang builtin_davix builtin_freetype builtin_ftgl builtin_glew builtin_llvm builtin_vdt builtin_zstd clad cocoa dataframe davix exceptions fftw3 fitsio fortran gdml http imt libcxx mathmore mlp mysql opengl pgsql pyroot pythia8 roofit webgui root7 shared sqlite ssl tmva tmva-cpu tmva-pymva spectrum vdt xml xrootd

bozzo@MacBook-Pro:BDTRICHEle> 

• however:

Thanks,
Matteo

[pcanal]

what about

(lldb) thread list

[bozzochet]

Hi,

I’m sorry. Before I think I gave a wrong “answer” (see below):

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff66e7b2c2 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff66f36bf1 libsystem_pthread.dylib`pthread_kill + 284
    frame #2: 0x00007fff66de56a6 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff66dae20d libsystem_c.dylib`__assert_rtn + 324
    frame #4: 0x0000000119a447a0 libGCocoa.so`ROOT::MacOSX::Details::CocoaPrivate::GetWindow(this=0x000000011825c9a0, windowID=99) const at CocoaPrivate.mm:127:4
    frame #5: 0x0000000119a8e39e libGCocoa.so`TGCocoa::SetDoubleBufferON(this=0x000000011825bd30) at TGCocoa.mm:3442:49
    frame #6: 0x0000000119a8e298 libGCocoa.so`TGCocoa::SetDoubleBuffer(this=0x000000011825bd30, windowID=99, mode=1) at TGCocoa.mm:3423:14
    frame #7: 0x0000000118412a18 libGpad.so`TCanvas::SetDoubleBuffer(this=0x0000000114dff7b0, mode=1) at TCanvas.cxx:1974:15
    frame #8: 0x000000011840c54b libGpad.so`TCanvas::FeedbackMode(this=0x0000000114dff7b0, set=false) at TCanvas.cxx:1114:7
    frame #9: 0x000000011840c278 libGpad.so`TCanvas::Close(this=0x0000000114dff7b0, option="") at TCanvas.cxx:781:7
    frame #10: 0x000000011840bb22 libGpad.so`TCanvas::Destructor(this=0x0000000114dff7b0) at TCanvas.cxx:685:4
    frame #11: 0x000000011840b96d libGpad.so`TCanvas::~TCanvas(this=0x0000000114dff7b0) at TCanvas.cxx:656:4
    frame #12: 0x000000011840bb85 libGpad.so`TCanvas::~TCanvas(this=0x0000000114dff7b0) at TCanvas.cxx:655:1
    frame #13: 0x00000001032f3d77 libCling.so`cling::IncrementalExecutor::runAndRemoveStaticDestructors(cling::Transaction*) + 391
    frame #14: 0x0000000103308e68 libCling.so`cling::Interpreter::runAndRemoveStaticDestructors() + 104
    frame #15: 0x0000000103129864 libCling.so`TCling::ResetGlobals(this=0x0000000100f20de0) at TCling.cxx:3473:18
    frame #16: 0x000000010013b169 libCore.so`TROOT::EndOfProcessCleanups(this=0x0000000100560d21) at TROOT.cxx:1251:21
    frame #17: 0x0000000100141160 libCore.so`TROOT::ShutDown() at TROOT.cxx:3090:14
    frame #18: 0x000000010039352b libCore.so`TUnixSystem::Exit(this=0x0000000100e05380, code=0, mode=true) at TUnixSystem.cxx:2141:4
    frame #19: 0x000000010015b2c8 libCore.so`TApplication::Terminate(this=0x0000000100f1c860, status=0) at TApplication.cxx:1697:16
    frame #20: 0x00000001000d5228 libRint.so`TRint::Terminate(this=0x0000000100f1c860, status=0) at TRint.cxx:693:21
    frame #21: 0x0000000100158b1a libCore.so`TApplication::ProcessLine(this=0x0000000100f1c860, line=".q", sync=false, err=0x00007ffeefbfb6f4) at TApplication.cxx:1353:7
    frame #22: 0x00000001000d38b2 libRint.so`TRint::ProcessLineNr(this=0x0000000100f1c860, filestem="ROOT_prompt_", line=".q", error=0x00007ffeefbfb6f4) at TRint.cxx:763:11
    frame #23: 0x00000001000d4c11 libRint.so`TRint::HandleTermInput(this=0x0000000100f1c860) at TRint.cxx:609:13
    frame #24: 0x00000001000d0a5a libRint.so`TTermInputHandler::Notify(this=0x0000000100ebcb60) at TRint.cxx:131:25
    frame #25: 0x00000001000d5ac9 libRint.so`TTermInputHandler::ReadNotify(this=0x0000000100ebcb60) at TRint.cxx:123:33
    frame #26: 0x000000010038fde2 libCore.so`TUnixSystem::CheckDescriptors(this=0x0000000100e05380) at TUnixSystem.cxx:1310:17
    frame #27: 0x0000000100389f01 libCore.so`TMacOSXSystem::DispatchOneEvent(this=0x0000000100e05380, pendingOnly=false) at TMacOSXSystem.mm:378:14
    frame #28: 0x00000001001f73be libCore.so`TSystem::InnerLoop(this=0x0000000100e05380) at TSystem.cxx:413:4
    frame #29: 0x00000001001f71fd libCore.so`TSystem::Run(this=0x0000000100e05380) at TSystem.cxx:363:13
    frame #30: 0x000000010015af74 libCore.so`TApplication::Run(this=0x0000000100f1c860, retrn=false) at TApplication.cxx:1623:13
    frame #31: 0x00000001000d31e6 libRint.so`TRint::Run(this=0x0000000100f1c860, retrn=false) at TRint.cxx:462:18
    frame #32: 0x0000000100001e84 root.exe`main(argc=1, argv=0x00007ffeefbfde18) at rmain.cxx:30:12
    frame #33: 0x00007fff66d403d5 libdyld.dylib`start + 1
    frame #34: 0x00007fff66d403d5 libdyld.dylib`start + 1
(lldb) thread list
Process 65993 stopped
* thread #1: tid = 0x3cb21b, 0x00007fff66e7b2c2 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  thread #2: tid = 0x3cb245, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #3: tid = 0x3cb246, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #4: tid = 0x3cb24f, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #5: tid = 0x3cb253, 0x00007fff66e7521a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread'
  thread #6: tid = 0x3cb286, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #7: tid = 0x3cb287, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #8: tid = 0x3cb288, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #9: tid = 0x3cb289, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10
  thread #10: tid = 0x3cb28b, 0x00007fff66e76bfa libsystem_kernel.dylib`__workq_kernreturn + 10

I really don’t know why before there was an “empty” answer. Most likely (and I’m sorry for this) I just opened only one TCanvas or, by accident, I closed both of them (accidental double click on the “x” of the TCanvas window) and then the .q was closing ROOT without any error. Sorry for this.

Matteo

[pcanal]

Does:

root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [2] .q

crashes?
What about:

root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas c
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] a.Close();
root [3] c.Close();
root [2] .q

what about if you add only one of the two Close()?

[pcanal]

@couet , the stack trace shows:

     frame #8: 0x000000011840c54b libGpad.so`TCanvas::FeedbackMode(this=0x0000000114dff7b0, set=false) at TCanvas.cxx:1114:7
    frame #9: 0x000000011840c278 libGpad.so`TCanvas::Close(this=0x0000000114dff7b0, option="") at TCanvas.cxx:781:7
    frame #10: 0x000000011840bb22 libGpad.so`TCanvas::Destructor(this=0x0000000114dff7b0) at TCanvas.cxx:685:4
    frame #11: 0x000000011840b96d libGpad.so`TCanvas::~TCanvas(this=0x0000000114dff7b0) at TCanvas.cxx:656:4
    frame #12: 0x000000011840bb85 libGpad.so`TCanvas::~TCanvas(this=0x0000000114dff7b0) at TCanvas.cxx:655:1
    frame #13: 0x00000001032f3d77 libCling.so`cling::IncrementalExecutor::runAndRemoveStaticDestructors(cling::Transaction*) + 391
    frame #14: 0x0000000103308e68 libCling.so`cling::Interpreter::runAndRemoveStaticDestructors() + 104
    frame #15: 0x0000000103129864 libCling.so`TCling::ResetGlobals(this=0x0000000100f20de0) at TCling.cxx:3473:18
    frame #16: 0x000000010013b169 libCore.so`TROOT::EndOfProcessCleanups(this=0x0000000100560d21) at TROOT.cxx:1251:21
    frame #17: 0x0000000100141160 libCore.so`TROOT::ShutDown() at TROOT.cxx:3090:14

Is is really needed to attempt to change the FeedbackMode during the tear down?

[bozzochet]

Ciao,

• no, was always like this: if you close all of them (and if there’s one only and you close, you closed all of them…) or none there’s no crash:

bozzo@MacBook-Pro:BDTRICHEle> root
Style set
root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [1] .q
bozzo@MacBook-Pro:BDTRICHEle> root
Style set
root [0] TCanvas a
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas c
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] .q

• if you close with Close() (independently from the number) there’s no crash:

bozzo@MacBook-Pro:BDTRICHEle> root
Style set
root [0] TCanvas c
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas a
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] c.Close()
root [3] a.Close()
root [4] .q
bozzo@MacBook-Pro:BDTRICHEle> root
Style set
root [0] TCanvas c
(TCanvas &) Name: c1 Title: c1
root [1] TCanvas a
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] a.Close()
root [3] .q

Thanks,
Matteo

[pcanal]

@bozzochet

no, was always like this: if you close all of them (and if there’s one only and you close, you closed all of them…) or none there’s no crash:

arrg … I finally grasps what you are saying and can reproduce the crash. For the record the order of operation for the (or one of the) crash(es) is.

root.exe # Start ROOT in non-batch mode
root [0] TCanvas a; // Create a first canvas
root [1] TCanvas b
(TCanvas &) Name: c1_n2 Title: c1_n2
root [2] // Close the SECOND canvas via the graphic interface; ie. either via the red close button or the File/Close menu item.
root [3] .q
2020-06-09 15:03:28.234 root.exe[46964:3242715] Fatal error: requested non-existing drawable 49
2020-06-09 15:03:28.234 root.exe[46964:3242715] This window not found among allocated/deleted drawables
Assertion failed: (winIter != fDrawables.end() && "GetWindow, non-existing window requested"), function GetWindow, file /Users/pcanal/root_working/code/rootcling/graf2d/cocoa/src/CocoaPrivate.mm, line 127.
Abort trap: 6

*NOTE* that omitting the trailing semi-colon is essential to reproduce the problem.

[Edited after noticing it is the second canvas that needs to be closed]