# script：python script “signal_handler_disconnect” does not work correctly



## fenghuyu (Jun 1, 2019)

Hey buddy,

I am currently writing a python script for obs studio. One of the functions is to get the name of the currently  scene when OBS Studio switches the scene. By referring to the documentation and some examples of python scripts, I can usel the following code to implement my functionality.


```
import obspython as obs

def script_load(settings):
    allrun()

def allrun():
    sources = obs.obs_enum_sources()
    sourcelist=obs.obs_frontend_get_scenes(sources)
    for so in sourcelist:
        sh=obs.obs_source_get_signal_handler(so)
        obs.signal_handler_connect(sh, "activate",checkscene)
    obs.source_list_release(sources)
    obs.sceneitem_list_release(sourcelist)

#Callback work
def checkscene(calldata):
    global Current_scene
    Current_scene=obs.obs_frontend_get_current_scene()
    cs_name=obs.obs_source_get_name(Current_scene)
    print(cs_name)
    obs.obs_source_release(Current_scene)

def script_properties():
    props = obs.obs_properties_create()
    obs.obs_properties_add_button(props, "button", "testunload", handlerdis)
    return props

def handlerdis(pp,p):
    sources = obs.obs_enum_sources()
    sourcelist=obs.obs_frontend_get_scenes(sources)
    for so in sourcelist:
        sh=obs.obs_source_get_signal_handler(so)
        obs.signal_handler_disconnect(sh, "activate",checkscene)
    obs.source_list_release(sources)
    obs.sceneitem_list_release(sourcelist)
```


But when the program is unloaded(through button ), I call signal_handler_disconnect to cancel the callback, and it does not works correctly. Is this a bug or is my use method wrong?


By the way,It seems that because the callback information is not canceled, after repeatedly triggering the callback, closing the obs studio will cause the program to crash. The error log is as follows.



```
Unhandled exception: c0000005
Date/Time: 2019-06-01, 16:47:00
Fault address: 7FFBF9FA3E02 (c:\program files\obs-studio\bin\64bit\w32-pthreads.dll)
libobs version: 23.1.0 (64-bit)
Windows version: 10.0 build 17763 (revision: 503; 64-bit)
CPU: AMD Ryzen 5 2600 Six-Core Processor


Thread 1D80 (Crashed)
Stack EIP Arg0 Arg1 Arg2 Arg3 Address
0000004A8B5AEE20 00007FFBF9FA3E02 0000000000000000 000002162139E488 0000000000000008 0000000000000004 w32-pthreads.dll!pthread_mutex_trylock+0x42
0000004A8B5AEF00 00007FFBF9FA339B 0000000000000000 0000000000000004 000002162139DD40 0000000000000008 w32-pthreads.dll!pthread_mutex_destroy+0x2b
0000004A8B5AEF50 00007FFBD930D34F 0000021612496D90 0000000000000008 0000000000000004 0000000000000004 obs.dll!obs_source_destroy+0x43f
0000004A8B5AF050 00007FFBD9310C99 00000216218EA890 0000000000000004 00000216232ABC80 0000000000000000 obs.dll!obs_source_release+0x49
0000004A8B5AF080 00007FFBD934359F 0000000000000000 0000000000000004 00000216232ABE00 00000216124B5A00 obs.dll!obs_sceneitem_destroy+0x7f
0000004A8B5AF0B0 00007FFBD9344E50 00000216232ABE00 00000216230BBC68 0000000000000008 0000000000000000 obs.dll!remove_all_items+0x180
0000004A8B5AF110 00007FFBD933F8DE 0000004A00000000 00007FFBD9364788 0000004A8B5AF168 0000000000000008 obs.dll!scene_destroy+0xe
0000004A8B5AF140 00007FFBD930D0E7 0000021614DD9CA0 0000000000000000 0000000000000000 0000000000000004 obs.dll!obs_source_destroy+0x1d7
0000004A8B5AF240 00007FFBD9320CCC 0000021614DD9CA0 0000000000000130 0000000000000000 00007FFBFE2DC7EB obs.dll!obs_free_data+0x5c
0000004A8B5AF270 00007FFBD9324BD7 0000000000000000 0000004A8B5AF710 0000000000000000 000002162366FBC0 obs.dll!obs_shutdown+0x387
0000004A8B5AF2C0 00007FF6E08C6FF2 0000004A8B5AF390 0000000000000000 0000004A8B5AF710 0000021612494120 obs64.exe!OBSApp::~OBSApp+0xa2
0000004A8B5AF300 00007FF6E08D3375 0000000000000000 00000216124B4820 0000021600000000 00000216124B5A40 obs64.exe!run_program+0x785
0000004A8B5AF610 00007FF6E08D59A0 0000000000000000 0000000000000000 0000000000000000 00000216124A5830 obs64.exe!main+0x670
0000004A8B5AF7E0 00007FF6E0A454E4 0000000000000001 0000000000000000 0000000000000000 0000000000000000 obs64.exe!WinMain+0x154
0000004A8B5AF870 00007FF6E0A445C2 0000000000000000 0000000000000000 0000000000000000 0000000000000000 obs64.exe!__scrt_common_main_seh+0x106
0000004A8B5AF8B0 00007FFBFED77974 0000000000000000 0000000000000000 0000000000000000 0000000000000000 kernel32.dll!0x7ffbfed77974
0000004A8B5AF8E0 00007FFC01B9A271 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ntdll.dll!0x7ffc01b9a271
```


----------



## Suk0m8u (May 14, 2021)

Still the same issue.
This forum seems to be dead.


----------



## Jim (May 16, 2021)

I'll check it before 27 is released.


----------



## Jim (May 18, 2021)

There is no bug with obs.signal_handler_disconnect(). If you have a crash on shutdown with a script, it's just due to some bug in your code. The scripting subsystems unfortunately use plain C bindings, so you have to manage your resources properly or you risk memory leaks and crashes. In this case, the error was printed to the log showing that you used some functions incorrectly. For the sourcelist variable, which you set via obs.obs_frontend_get_scenes(sources), you were using obs.sceneitem_list_release(sourcelist) when you're supposed to use obs.source_list_release(sourcelist), thus causing a memory leak because references to all scenes are never freed anymore. Additionally, obs.obs_frontend_get_scenes() does not have any parameters, so you should be doing obs.obs_frontend_get_scenes() instead. So you were basically calling obs.obs_enum_sources() for no reason, because the sources variable was never actually used for anything. If you were trying to get scene items, then you were calling the wrong functions in the first place.

In the future, I would like to improve the bindings of the scripting implementations to prevent this sort of confusion. Unfortunately we'll be stuck with straight C bindings for quite a long time.


----------

