Windows app not closing properly

[idenc]

After the latest update, Netron remains open taking up memory and CPU after closing the program. I must close it through task manager each time. I am on Windows 10

[lutzroeder]

Is this happening reliably with3.3.2 or can you provide specific steps to reproduce this? Opening the app, loading a model and closing on Windows 10 1903 seems to work.

[idenc]

It happens reliably with 3.3.2 if I open more than one model at the same time. I tried reinstalling to no avail. I am on Windows 10 1803 and can't update due to it being a work computer.

[lutzroeder]

1. Open App
2. File > Open... > select file
3. File > Open... > select file
4. File > Exit
5. Open Task Manager > Details > Netron is not listed

Are you doing anything different?

[idenc]

Generally, I just double click the files to launch the app but if I use the above method it still remains open. Here is a screenshot with multiple instances of Netron open in task manager but the app is not open.

[MasterGG]

I also met this problem in windows10，and i installed the latest version.

[CangHaiQingYue]

I also met this problem in windows10,wtih 3.3.6.
And I'd love to try 3.4.1.
Thank you very much.

[siddharth-krishna]

I'm also having this issue with Netron 4.5.4 and Windows 10 2004. I'd be happy to help you reproduce this behavior, if possible.

[pArtheum]

Hi, i have the same issue on Windows 10 using Netron through conda. It looks like the netron.stop() function stays in an infinite loop.

[lutzroeder]

@pArtheum Python app is a different issue. This is tracking the Electron app. Can you investigate and submit a fix?

[ryusaeba]

I am also experiencing the netron greedly consume the memory. When the issue is happen, it will consume all the dram. By adding dram from 8 to 16, it still try to consume all 16 and then consume the virtual memory.
os is win 10.
Also, I usually use netron to veiw two or three model at the same time.

[surprisedong]

i have the same issue, is there any solutions

[AlexRibard]

I have the same issue.
I also have rogue processes taking up RAM even if I close Netron

[amirebrahimi]

No Netron icon open on my desktop (v4.6.4). Originally launched by double clicking on a file. Memory isn't growing at any radical pace, but CPU staying up around 14-20%. My fans were going on my laptop, so I was wondering what was going on.

I decided to create a dump, but without symbols it makes it hard to see what is going on below the Windows parts.
ntdll.dll!RtlpFreeHeapInternal() Unknown
ntdll.dll!RtlFreeHeap() Unknown
Netron.exe!00007ff75dc005f9() Unknown

Any chance we could get symbols to help debug this?

[lutzroeder]

@amirebrahimi DEVELOPMENT.md has instructions to run the Electron app locally. setting-up-symbol-server for getting Electron symbols.

[amirebrahimi]

Thanks @lutzroeder. I've never developed with Electron, so I'm seeing now that this may be an issue with Electron then. Here's the full stack btw from above:

 	ntdll.dll!RtlpFreeHeapInternal()	Unknown
 	ntdll.dll!RtlFreeHeap()	Unknown
 	Netron.exe!viz::Gpu::EstablishRequest::~EstablishRequest() Line 193	C++
 	[Inline Frame] Netron.exe!base::RefCountedThreadSafe<viz::Gpu::EstablishRequest,base::DefaultRefCountedThreadSafeTraits<viz::Gpu::EstablishRequest>>::DeleteInternal(const viz::Gpu::EstablishRequest * x) Line 411	C++
 	[Inline Frame] Netron.exe!base::DefaultRefCountedThreadSafeTraits<viz::Gpu::EstablishRequest>::Destruct(const viz::Gpu::EstablishRequest * x) Line 366	C++
 	[Inline Frame] Netron.exe!base::RefCountedThreadSafe<viz::Gpu::EstablishRequest,base::DefaultRefCountedThreadSafeTraits<viz::Gpu::EstablishRequest>>::Release() Line 400	C++
 	[Inline Frame] Netron.exe!scoped_refptr<viz::Gpu::EstablishRequest>::Release(viz::Gpu::EstablishRequest * ptr) Line 322	C++
 	[Inline Frame] Netron.exe!scoped_refptr<viz::Gpu::EstablishRequest>::~scoped_refptr() Line 224	C++
 	[Inline Frame] Netron.exe!scoped_refptr<viz::Gpu::EstablishRequest>::reset() Line 254	C++
 	Netron.exe!viz::Gpu::OnEstablishedGpuChannel() Line 384	C++
 	[Inline Frame] Netron.exe!viz::Gpu::EstablishRequest::FinishOnMain() Line 159	C++
 	Netron.exe!viz::Gpu::EstablishGpuChannelSync() Line 341	C++
 	Netron.exe!content::RenderThreadImpl::EstablishGpuChannelSync() Line 1641	C++
 	Netron.exe!content::RenderThreadImpl::RequestNewLayerTreeFrameSink(content::RenderWidget * render_widget, const GURL & url, base::OnceCallback<void (std::__1::unique_ptr<cc::LayerTreeFrameSink,std::__1::default_delete<cc::LayerTreeFrameSink>>, std::__1::unique_ptr<cc::RenderFrameMetadataObserver,std::__1::default_delete<cc::RenderFrameMetadataObserver>>)> callback, const char * client_name) Line 1724	C++
 	Netron.exe!content::RenderWidget::RequestNewLayerTreeFrameSink(base::OnceCallback<void (std::__1::unique_ptr<cc::LayerTreeFrameSink,std::__1::default_delete<cc::LayerTreeFrameSink>>, std::__1::unique_ptr<cc::RenderFrameMetadataObserver,std::__1::default_delete<cc::RenderFrameMetadataObserver>>)> callback) Line 405	C++
 	Netron.exe!blink::WebFrameWidgetBase::RequestNewLayerTreeFrameSink(base::OnceCallback<void (std::__1::unique_ptr<cc::LayerTreeFrameSink,std::__1::default_delete<cc::LayerTreeFrameSink>>, std::__1::unique_ptr<cc::RenderFrameMetadataObserver,std::__1::default_delete<cc::RenderFrameMetadataObserver>>)> callback) Line 714	C++
 	Netron.exe!blink::WidgetBase::RequestNewLayerTreeFrameSink(base::OnceCallback<void (std::__1::unique_ptr<cc::LayerTreeFrameSink,std::__1::default_delete<cc::LayerTreeFrameSink>>, std::__1::unique_ptr<cc::RenderFrameMetadataObserver,std::__1::default_delete<cc::RenderFrameMetadataObserver>>)> callback) Line 451	C++
 	Netron.exe!blink::LayerTreeView::RequestNewLayerTreeFrameSink() Line 244	C++
 	[Inline Frame] Netron.exe!base::internal::InvokeHelper<1,void>::MakeItSo(void(viz::SkiaOutputSurfaceImpl::*)() && functor, base::WeakPtr<viz::SkiaOutputSurfaceImpl> && weak_ptr) Line 657	C++
 	[Inline Frame] Netron.exe!base::internal::Invoker<base::internal::BindState<void (viz::SkiaOutputSurfaceImpl::*)(),base::WeakPtr<viz::SkiaOutputSurfaceImpl>>,void ()>::RunImpl(void(viz::SkiaOutputSurfaceImpl::*)() && functor, std::__1::tuple<base::WeakPtr<viz::SkiaOutputSurfaceImpl>> && bound, std::__1::integer_sequence<unsigned long long,0>) Line 710	C++
 	Netron.exe!base::internal::Invoker<base::internal::BindState<void (viz::SkiaOutputSurfaceImpl::*)(),base::WeakPtr<viz::SkiaOutputSurfaceImpl>>,void ()>::RunOnce(base::internal::BindStateBase * base) Line 683	C++
 	[Inline Frame] Netron.exe!base::OnceCallback<void ()>::Run() Line 100	C++

[amirebrahimi]

I think it is related to electron/electron#20277

[amirebrahimi]

Do any of your dependencies make use of SharedWorker?

[amirebrahimi]

This could also be the issue: atom/atom#17672 (comment)
Perhaps try replacing https://github.com/lutzroeder/netron/blob/main/source/app.js#L891 with fs.writeFile() (async version)

[amirebrahimi]

Or rather, change https://github.com/lutzroeder/netron/blob/main/source/app.js#L67
to 'before-quit' in case it is an issue with trying to do something while the app is shutting down.

[lutzroeder]

@amirebrahimi can you try locally if this fixes the issue? To create an unsigned release build run npx electron-builder --win.

[amirebrahimi]

I'd be happy to when I can find a solid repro, which you've asked for :) I tried a variety of things, such as launching multiple files at once and closing very quickly (ctrl-w), closing apps from the taskbar while not focused, closing with the X button.

[amirebrahimi]

Oddly enough, just after I wrote the previous comment above I then noticed I had a rogue process, so I had a hunch and finally was able to boil it down to a simple repro:

1. Double click on one .onnx file to open in Netron
2. Double click on a different .onnx file to open in Netron
3. Switch to another app (I had task manager open to verify the rogue process)
4. Close the Netron apps directly from the taskbar (i.e. without focusing)

The main issue is that even though a second instance is supposed to quit (via electron.app.quit) it continues past that statement and executes remaining code, which I think fires up the render sub-process, but then there is nothing to close the app except the task manager because there is no window. By returning immediately from the constructor this doesn't happen.