Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to correctly stop uiTimer? #395

Open
msink opened this issue Jun 21, 2018 · 9 comments
Open

how to correctly stop uiTimer? #395

msink opened this issue Jun 21, 2018 · 9 comments
Milestone

Comments

@msink
Copy link
Contributor

msink commented Jun 21, 2018

Strange thing - libui timer example works just fine, but when converted to Kotlin - crashes on exit:

$ gdb timer.exe
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from timer.exe...(no debugging symbols found)...done.
(gdb) r
Starting program: F:\src\kotlin-libui\build\konan\bin\mingw_x64\timer.exe
[New Thread 12232.0x2b0c]
warning: [libui] F:\src\kotlin-libui\libui\windows\alloc.cpp:25:uninitAlloc() You have a bug: Some data was leaked; either you left a uiControl lying around or there's a bug in libui itself. Leaked data:
0x37af40 uiprivTimer


Program received signal SIGTRAP, Trace/breakpoint trap.
0x000007fefcf531f3 in KERNELBASE!DebugBreak ()
   from C:\Windows\system32\KernelBase.dll

Don't know how to fix this.

@simplexidev
Copy link
Contributor

simplexidev commented Jul 4, 2018

Here's the answer @msink. I was looking for the answer as well.

EDIT: Literally missed you commented above that. My bad.

@msink
Copy link
Contributor Author

msink commented Jul 4, 2018

So currenty to correctly close programm with running 1-second timer, I have to wait in worst case 1 second? It's crazy.
There should be a way to stop it from outside, like pthread_cancel. Or just auto-stop on program end.

@simplexidev
Copy link
Contributor

It seems to be that way, but I'd confirm that with @andlabs.

I like the idea of being able to manually stop the timer at any point.

@cody271
Copy link
Contributor

cody271 commented Jul 4, 2018

See previous discussion of timer cancellation here.

@msink
Copy link
Contributor Author

msink commented Jul 4, 2018

See previous discussion of timer cancellation here.

It does not work - if handler is cleared in language binding, but on libui level keep running - after closing program stopped on breakpoint in

libui\windows\alloc.cpp:25:uninitAlloc() You have a bug: Some data was leaked; either you left a uiControl lying around or there's a bug in libui itself. Leaked data:
0x37af40 uiprivTimer

@andlabs
Copy link
Owner

andlabs commented Jul 4, 2018

Note that you don't need to call uiUninit() if you're just going to exit immediately afterward. That's there to make sure I'm doing things correctly. And of course, I'm not doing things correctly here =P I need to properly clean up timers in uiUninit().

@andlabs
Copy link
Owner

andlabs commented Aug 9, 2018

All right, crashing fixed on all platforms it's affected on. Other platforms leave this as a TODO for now. There should probably be something in the tester for this...

@msink
Copy link
Contributor Author

msink commented Aug 9, 2018

Thanks, closed my issue. So this should be closed too?

@andlabs
Copy link
Owner

andlabs commented Aug 9, 2018

Not yet; tester first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants