Problems using libsrtp on EL9 - c

I'm having some issues with enabling the res_srtp module in Asterisk. Every attempt results in this not-so-helpful error message:
WARNING[47044] res_srtp.c: Failed to initialize libsrtp
ERROR[47044] loader.c: *** Failed to load module res_srtp.so
ERROR[47044] asterisk.c: Module initialization failed. ASTERISK EXITING!
I'd like to fix this and get it running, so now we get into the programming side of things. I'm not a C programmer by trade, but I was able to use my limited gdb skills to trace the error back through libsrtp's crypto_kernel_init() function. The error occurs when trying to enable the AES-GCM-128 cipher.
I was only able to get as far as PK11_Encrypt() in the NSS library, where I was unable to step into this line of code. I think this is because (again, very limited C knowledge) it's a macro and not a true function?
crv = PK11_GETTAB(slot)->C_EncryptInit(session, &mech, symKey->objectID);
// returns 113
So my question is either, how can I proceed with debugging this to a point where I can file a bug report with someone, or (preferably) has anyone got libsrtp working in this environment? There were very few other reports of similar problems, likely because EL9 is not in wide use yet.
My distro (AlmaLinux) is running NSS 3.71, and I've tried updating to NSS 3.79 with no change.
Here's the backtrace from where I was able to get to, if it's of any help.
#0 PK11_Encrypt (symKey=0x555555ea1a00, mechanism=mechanism#entry=4231, param=param#entry=0x7fffffffc9a0,
out=out#entry=0x7fffffffcb50 "\331\061\062%\370\204\006\345\245Y\tů\365&\232\206\247\251S\025\064\367\332.L0=\212\061\212r\034<\f\225\225h\tS/\317\016$I\246\265%\261j\355\365\252\r\346W\272c{9", outLen=outLen#entry=0x7fffffffca3c, maxLen=<optimized out>,
data=0x7fffffffcb50 "\331\061\062%\370\204\006\345\245Y\tů\365&\232\206\247\251S\025\064\367\332.L0=\212\061\212r\034<\f\225\225h\tS/\317\016$I\246\265%\261j\355\365\252\r\346W\272c{9", dataLen=60) at ../pk11wrap/pk11obj.c:972
#1 0x00007ffff456a455 in srtp_aes_gcm_nss_do_crypto (enc_len=0x7fffffffca3c,
buf=0x7fffffffcb50 "\331\061\062%\370\204\006\345\245Y\tů\365&\232\206\247\251S\025\064\367\332.L0=\212\061\212r\034<\f\225\225h\tS/\317\016$I\246\265%\261j\355\365\252\r\346W\272c{9", encrypt=1, cv=0x5555562a19c0) at crypto/cipher/aes_gcm_nss.c:297
#2 srtp_aes_gcm_nss_encrypt (cv=0x5555562a19c0, buf=<optimized out>, enc_len=0x7fffffffca3c) at crypto/cipher/aes_gcm_nss.c:345
#3 0x00007ffff456cb24 in srtp_cipher_type_test (ct=0x7ffff457a6c0 <srtp_aes_gcm_128>, test_data=0x7ffff457a420 <srtp_aes_gcm_test_case_0>)
at crypto/cipher/cipher.c:297
#4 0x00007ffff456d545 in srtp_cipher_type_test (ct=<optimized out>, test_data=<optimized out>) at crypto/cipher/cipher.c:605
#5 0x00007ffff456d58d in srtp_cipher_type_self_test (ct=<optimized out>) at crypto/cipher/cipher.c:613
#6 0x00007ffff457005d in srtp_crypto_kernel_do_load_cipher_type (replace=0, id=6, new_ct=0x7ffff457a6c0 <srtp_aes_gcm_128>)
at crypto/kernel/crypto_kernel.c:293
#7 srtp_crypto_kernel_load_cipher_type (new_ct=new_ct#entry=0x7ffff457a6c0 <srtp_aes_gcm_128>, id=id#entry=6) at crypto/kernel/crypto_kernel.c:343
#8 0x00007ffff457036e in srtp_crypto_kernel_init () at crypto/kernel/crypto_kernel.c:139
#9 srtp_crypto_kernel_init () at crypto/kernel/crypto_kernel.c:72
#10 0x00007ffff457040d in srtp_init () at srtp/srtp.c:2729
#11 0x00007ffff458718d in res_srtp_init () at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/res/res_srtp.c:1237
#12 load_module () at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/res/res_srtp.c:1272
#13 0x000055555566c4dc in start_resource.part.0.lto_priv.0 (mod=0x555555a469d0) at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:1718
#14 0x0000555555665517 in start_resource (mod=0x555555a469d0) at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:1692
#15 start_resource_attempt (mod=mod#entry=0x555555a469d0, count=count#entry=0x7fffffffce94)
at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:1894
#16 0x000055555566862f in start_resource_list (mod_count=0x7fffffffce94, resources=0x7fffffffceb0)
at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:1991
#17 load_resource_list (mod_count=<synthetic pointer>, load_order=0x7fffffffcea0) at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:2173
#18 load_modules () at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/loader.c:2396
#19 0x000055555559e074 in asterisk_daemon (isroot=<optimized out>, rungroup=<optimized out>, runuser=<optimized out>)
at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/asterisk.c:4258
#20 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/asterisk-16.28.0-0.el9.x86_64/main/asterisk.c:4025

After going through the debug steps a few more times, I tried searching the initial return value from srtp_kernel_init() which was srtp_err_status_cipher_fail; I ended up finding a resolved issue with the same symptoms for Fedora Linux:
The issue turns out to be an incompatibility with nss-3.63 shipped with F34. The attached patch adds NSS_PKCS11_2_0_COMPAT defines to 2 header files to enable the backward compatibility. The same fix is already in the upstream github repo and is targeted for the next libsrtp release.
I was able to apply their patch to the libsrtp 2.3.0 codebase, and the library is successfully loading now:
index 4d6031f..b1da343 100644
--- a/crypto/include/aes_gcm.h
+++ b/crypto/include/aes_gcm.h
## -66,6 +66,8 ## typedef struct {
#ifdef NSS
+#define NSS_PKCS11_2_0_COMPAT 1
+
#include <nss.h>
#include <pk11pub.h>
index ad306dd..a57564f 100644
--- a/crypto/include/aes_icm_ext.h
+++ b/crypto/include/aes_icm_ext.h
## -65,6 +65,8 ## typedef struct {
#ifdef NSS
+#define NSS_PKCS11_2_0_COMPAT 1
+
#include <nss.h>
#include <pk11pub.h>
I'm not sure the second hunk is needed, as ICM ciphers were loading fine, but I applied it anyway.

Related

Macro substitution on a dynamically linked shared object

I have a compiled source code executable which has redefined malloc() with a custom function CustMalloc() using macro substitution.
As seen from the below backtrace, the compiled source code executable is supposed to be dynamically linked with libMRegAccess.so and libusb-1.0.so.0 shared objects. Both these shared objects were independently compiled and they have no means of knowing the above macro substitution during their compilation.
Now, bsd-asprintf.c I presume is a linux source file and the call to asprintf() and vasprintf() are called from the libusb-1.0.so.0 shared object when executing, which in turn tries to call malloc().
I'm unable to understand why the custom function CustMalloc() is getting called instead of the actual malloc().
FYI, the semaphore that is required in this backtrace is not yet created and hence the crash. The expectation is that the CustMalloc() should not be invoked in this code flow as the call is being made from an independently built shared object.
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1269]
0x0000007fb7f896cc in __new_sem_wait_fast () from /lib//libpthread.so.0
(gdb) bt
#0 0x0000007fb7f896cc in __new_sem_wait_fast () from /lib//libpthread.so.0
#1 0x0000007fb7f898fc in sem_wait##GLIBC_2.17 () from /lib//libpthread.so.0
#2 0x0000000001b09000 in SemTake (SemId=0x0) at <compiled_source_code.c>
#3 0x0000000000d6cffc in ContextLock () at <compiled_source_code.c>
#4 0x0000000000d993e4 in CustMalloc (size=128) at <compiled_source_code.c>
#5 0x0000000001c88a2c in vasprintf (str=0x7fb5eaf5f8, fmt=0x7fb7e8a640 "usb%s", ap=...) at bsd-asprintf.c:61
#6 0x0000000001c88c50 in asprintf (str=0x7fb5eaf5f8, fmt=0x7fb7e8a640 "usb%s") at bsd-asprintf.c:120
#7 0x0000007fb7e853cc in linux_enumerate_device () from /usr/lib/libusb-1.0.so.0
#8 0x0000007fb7e854c4 in sysfs_scan_device () from /usr/lib/libusb-1.0.so.0
#9 0x0000007fb7e85b80 in op_init () from /usr/lib/libusb-1.0.so.0
#10 0x0000007fb7e7dd1c in libusb_init () from /usr/lib/libusb-1.0.so.0
#11 0x0000007fb7ea65fc in cyusb_open(unsigned short, unsigned short) () from /usr/lib/libMRegAccess.so
#12 0x0000007fb7ea33f4 in InitDefaultUSBConn () from /usr/lib/libMRegAccess.so
#13 0x0000007fb7ea58e0 in openDefaultUSBDriver () from /usr/lib/libMRegAccess.so
#14 0x00000000010ddd94 in InitDrv () at <compiled_source_code.c>
#15 ... at <compiled_source_code.c>
#16 ... at <compiled_source_code.c>
#17 ... at <compiled_source_code.c>
#18 ... at <compiled_source_code.c>
#19 0x0000007fb7f80fd0 in start_thread () from /lib//libpthread.so.0
#20 0x0000007fb7d8cf60 in ?? () from /lib//libc.so.6
I'm unable to understand why the custom function CustMalloc() is getting called instead of the actual malloc()
This appears to be happening because you compiled and linked bsd-asprintf.c (with your macro redefinition) into your main executable.
You can tell that asprintf and CustMalloc are part of your binary, because their addresses are very different from other library routines (such as linux_enumerate_device or sem_wait).
If you want to know where asprintf is defined (which archive library or object file it comes from), relink your executable with -Wl,-y,asprintf flag, and the linker will tell you.

Are TCL Regular Expressions Shared Across Interpreters - TclReExec Program terminated with signal 11, Segmentation fault?

In a single EXE process, are TCL regular expressions shared by each interpreter instance returned by Tcl_CreateInterp? How could threads with 4 different interpreter instances (0x94fbcd8,0x94dff20,0x94c4170,0x94a8760) all be making a call like TclReFree (re=0x86b0444) at ./../generic/regfree.c:52?
This comment in the TCL manual hints that objects may be shared...
Tcl objects are allocated on the heap and are shared as much as possible to
reduce storage requirements. Reference counting is used to determine when an
object is no longer needed and can safely be freed.
Source: https://www.tcl.tk/man/tcl8.4/TclLib/Object.htm
We're encountering crashes in our 32-bit server application. We've isolated the root cause to a TCL regular expression shared between threads concurrently running in separate TCL interpreter instances.
The interpreters are failing on this line of TCL
regsub "\\*" $s "\\*" s
The application concurrently runs TCL 8.4.11 interpreter instances. Each interpreter is executing "user TCL scripts" in separate threads. The app creates threads that "own" 1 interpreter instance created using Tcl_CreateInterp. Each thread then tells the interpreter instance to run a "user TCL script" with Tcl_EvalObjv. The crash happens when each interpreter is configured to run the same "user TCL script" on the line containing the regsub shown above.
This app has been running in dozens of different production environments for over 15 years. In the current environment, the app is running on Red Hat Linux 6.5 64-bit.
The core dump looks like...
Program terminated with signal 11, Segmentation fault.
#0 0x0811c020 in miss ()
(gdb) bt
#0 0x0811c020 in miss ()
#1 0x0811b7ed in shortest ()
#2 0x0811a4fa in find ()
#3 0x0811a429 in TclReExec ()
#4 0x080fc83f in RegExpExecUniChar ()
#5 0x080fc970 in Tcl_RegExpExecObj ()
#6 0x080bb9f1 in Tcl_RegsubObjCmd ()
#7 0x080b027a in TclEvalObjvInternal ()
#8 0x080d2726 in TclExecuteByteCode ()
#9 0x080d1bd1 in TclCompEvalObj ()
#10 0x080fbd6c in TclObjInterpProc ()
#11 0x080b027a in TclEvalObjvInternal ()
#12 0x080d2726 in TclExecuteByteCode ()
#13 0x080d1bd1 in TclCompEvalObj ()
#14 0x080fbd6c in TclObjInterpProc ()
#15 0x080b027a in TclEvalObjvInternal ()
#16 0x080b0527 in Tcl_EvalObjv ()
After recompiling the app with a version of TCL with the compile flag --enable-symbols=mem and linked with D.U.M.A. - Detect Unintended Memory Access http://duma.sourceforge.net/ (a fork of Electric Fence to help catch buffer overruns), I'm getting a core dump like
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xea8eeb70 (LWP 31004)]
0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
52 (*((struct fns *)re->re_fns)->free)(re);
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6_5.2.i686
(gdb) list
47 regfree(re)
48 regex_t *re;
49 {
50 if (re == NULL)
51 return;
52 (*((struct fns *)re->re_fns)->free)(re);
53 }
(gdb) bt
#0 0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
#1 0x08124360 in FreeRegexp (regexpPtr=0x86b0440) at ./../generic/tclRegexp.c:989
#2 0x08123ec2 in FreeRegexpInternalRep (objPtr=0xf64041b8) at ./../generic/tclRegexp.c:746
#3 0x08128cab in SetStringFromAny (interp=0x0, objPtr=0xf64041b8) at ./../generic/tclStringObj.c:1762
#4 0x08127894 in Tcl_GetUnicodeFromObj (objPtr=0xf64041b8, lengthPtr=0xea8ecee8) at ./../generic/tclStringObj.c:567
#5 0x080c3e9a in Tcl_RegsubObjCmd (dummy=0x0, interp=0x94fbcd8, objc=4, objv=0x94fbf28) at ./../generic/tclCmdMZ.c:718
#6 0x080b1386 in TclEvalObjvInternal (interp=0x94fbcd8, objc=5, objv=0x94fbf24, command=0x0, length=0, flags=0) at ./../generic/tclBasic.c:3088
#7 0x080e5a88 in TclExecuteByteCode (interp=0x94fbcd8, codePtr=0x95174e0) at ./../generic/tclExecute.c:1417
#8 0x080e4959 in TclCompEvalObj (interp=0x94fbcd8, objPtr=0x95097f0) at ./../generic/tclExecute.c:981
#9 0x08122a35 in TclObjInterpProc (clientData=0x9514520, interp=0x94fbcd8, objc=2, objv=0x94fbf1c) at ./../generic/tclProc.c:1100
#10 0x080b1386 in TclEvalObjvInternal (interp=0x94fbcd8, objc=2, objv=0x94fbf1c, command=0x0, length=0, flags=0) at ./../generic/tclBasic.c:3088
#11 0x080e5a88 in TclExecuteByteCode (interp=0x94fbcd8, codePtr=0xf64011f8) at ./../generic/tclExecute.c:1417
#12 0x080e4959 in TclCompEvalObj (interp=0x94fbcd8, objPtr=0x9513f68) at ./../generic/tclExecute.c:981
#13 0x08122a35 in TclObjInterpProc (clientData=0x9514d10, interp=0x94fbcd8, objc=2, objv=0xea8ee34c) at ./../generic/tclProc.c:1100
#14 0x080b1386 in TclEvalObjvInternal (interp=0x94fbcd8, objc=2, objv=0xea8ee34c, command=0x81a4ffe "", length=0, flags=0) at ./../generic/tclBasic.c:3088
#15 0x080b15e4 in Tcl_EvalObjv (interp=0x94fbcd8, objc=2, objv=0xea8ee34c, flags=0) at ./../generic/tclBasic.c:3204
#16 0x0808a812 in run_tcl_proc (pDevice=0x82405e0, pInterp=0x830d340, iNumArgs=2, objv=0xea8ee34c, bIsCommand=0 '\000', pCommand=0x0)
#17 0x08093492 in Tcl_begin_next_state (pDevice=0x82405e0, iNextState=RunPoll, pCommand=0x0)
#18 0x08093579 in Tcl_port_thread (dummy=0x8232c00)
#19 0x0014fb39 in start_thread () from /lib/libpthread.so.0
#20 0x00967d7e in clone () from /lib/libc.so.6
(gdb)
This gdb sessions also clearly shows concurrent threads executing regfree on the same regular expression, even though each thread's TCL interpreter instance is completely thread bound. There should be zero sharing between threads. The only thing they have in common is they are executing a "user TCL script" file with the same filename. The files were all loaded with Tcl_EvalFile into per-thread interpreter instances.
(gdb) info threads
45 Thread 0xe30e2b70 (LWP 31017) 0x00110430 in __kernel_vsyscall ()
--snip--
34 Thread 0xe9eedb70 (LWP 31005) 0x00110430 in __kernel_vsyscall ()
* 33 Thread 0xea8eeb70 (LWP 31004) 0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
32 Thread 0xeb2efb70 (LWP 31003) 0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
31 Thread 0xebcf0b70 (LWP 31002) 0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
30 Thread 0xec6f1b70 (LWP 31001) 0x08151496 in TclReFree (re=0x86b0444) at ./../generic/regfree.c:52
29 Thread 0xed0f2b70 (LWP 31000) 0x00110430 in __kernel_vsyscall ()
--snip--
1 Thread 0xf7fec8d0 (LWP 30970) 0x00110430 in __kernel_vsyscall ()
(gdb)
Note that this question is a completely separate crash from my previous question alloc: invalid block - Are Tcl_IncrRefCount and Tcl_DecrRefCount thread safe for threaded Tcl / 1 interp per thread?.
After digging through the app's code, I found a case where in thread A an interpreter is created and asked to run a proc but then in thread B used to run many other procs. I'm guessing this may be the root cause of this crash. Strangely, the app doesn't crash on Windows but crashes immediately (most of the time) on Linux. The app creates threads:
On Windows, using the Win32 API.
On Linux, using POSIX Threads / pthreads.
To answer your immediate question, REs are shared by two mechanisms. Firstly, they're bound to the internal representation of the Tcl_Obj values generated from the values in your script (e.g., the literals and the results of operations). Secondly, they're also stored in a size-bounded per-thread LRU cache.
Both of these mechanisms are strictly thread-bound. REs are not shared between threads; Tcl shares extremely little between threads.
However, there are a number of larger issues in your question.
If you're sending messages (err, scripts) between threads for execution, you're strongly recommended to use the Thread extension for this, as this takes care to copy things that need to be copied. The Thread extension ships with a full distribution of Tcl 8.6 (it's now a contributed package, along with [incr Tcl], SQLite and TDBC) but it should be available separately for older versions of Tcl.
Also, you're using a doubly-unsupported version of Tcl. The most recent version of 8.4 is 8.4.20 (which should be a drop-in replacement) and even that has been out of security/build support for several years now. You really are recommended to upgrade. 8.5.17 is the current long-term support release, and 8.6.3 is the current production release. (They're also quite a bit faster on a lot of code.)

alloc: invalid block - Are Tcl_IncrRefCount and Tcl_DecrRefCount thread safe for threaded Tcl / 1 interp per thread?

Our 32-bit server application statically embeds tcl 8.4.11. On Red Hat Linux 6.5 64-bit we're encountering crashes / core dumps. The failure looks like
alloc: invalid block: 0xf6f00f58: 88 f6 0
At the bottom of the question, I've documented two different core dumps we've seen.
We've isolated a potential root cause to a TCL object shared between two threads concurrently running separate TCL interpreter instances. We think it's because TCL object is passed to Tcl_IncrRefCount / Tcl_DecrRefCount from these concurrently executing TCL interpreters.
Are Tcl_IncrRefCount / Tcl_DecrRefCount thread safe when TCL is compiled threaded?
Are TCL objects shared by TCL interpreter instances? Is there any way to disable TCL object sharing across interpreter instances?
Is the situation any better in TCL version 8.6.3?
(gdb) bt
#0 __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1 0x001b7871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x001b914a in abort () at abort.c:92
#3 0x080f611c in Tcl_PanicVA ()
#4 0x080f613b in Tcl_Panic ()
#5 0x0810133c in Ptr2Block ()
#6 0x08100e04 in TclpFree ()
#7 0x080b46a7 in Tcl_Free ()
#8 0x08100686 in FreeStringInternalRep ()
#9 0x080fdac1 in ResetObjResult ()
#10 0x080fd316 in Tcl_GetStringResult ()
#11 0x0808aaad in run_tcl_proc (pDevice=0x8e0ba08, pInterp=0x8d798c0, iNumArgs=2, objv=0x115434c, bIsCommand=0 '\000', pCommand=0x0)
#12 0x08093672 in Tcl_begin_next_state (pDevice=0x8e0ba08, iNextState=RunPoll, pCommand=0x0)
#13 0x08093759 in Tcl_port_thread (dummy=0x8d1cab8)
#14 0x008bcb39 in start_thread (arg=0x1154b70) at pthread_create.c:301
#15 0x0026fc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)
(gdb) bt
#0 __kernel_vsyscall () at arch/x86/vdso/vdso32/sysenter.S:49
#1 0x00395871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x0039714a in abort () at abort.c:92
#3 0x080f611c in Tcl_PanicVA ()
#4 0x080f613b in Tcl_Panic ()
#5 0x0810133c in Ptr2Block ()
#6 0x08100e04 in TclpFree ()
#7 0x080b46a7 in Tcl_Free ()
#8 0x080d21b6 in TclExecuteByteCode ()
#9 0x080d1bc1 in TclCompEvalObj ()
#10 0x080fbd5c in TclObjInterpProc ()
#11 0x080b026a in TclEvalObjvInternal ()
#12 0x080d2716 in TclExecuteByteCode ()
#13 0x080d1bc1 in TclCompEvalObj ()
#14 0x080fbd5c in TclObjInterpProc ()
#15 0x080b026a in TclEvalObjvInternal ()
#16 0x080b0517 in Tcl_EvalObjv ()
#17 0x0808aa02 in run_tcl_proc (pDevice=0x94a2500, pInterp=0xac2bba0, iNumArgs=2, objv=0x11b034c, bIsCommand=0 '\000', pCommand=0x0)
#18 0x08093672 in Tcl_begin_next_state (pDevice=0x94a2500, iNextState=RunPoll, pCommand=0x0)
#19 0x08093759 in Tcl_port_thread (dummy=0x9365e98)
#20 0x00356b39 in start_thread (arg=0x11b0b70) at pthread_create.c:301
#21 0x0044dc2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb)
The calls Tcl_IncrRefCount (actually a simple macro) and Tcl_DecrRefCount (a complicated macro) are sort of thread safe, but only because each Tcl_Obj should only ever be accessed from the thread that created it; parallel calls to T_IRC and T_DRC are fine, so long as they're on different values. The plus side of this is that accesses don't need locking (and the memory manager for Tcl_Obj structures takes advantage of this).
Note that multi-threaded access is not a good plan at all unless you're very careful, since even reader operations like Tcl_GetIntFromObj can write to the underlying structure if a type transformation needs to be applied. These operations are not locked. Doing it at all needs very intimate knowledge of the current type of the value — not something that you're usually encouraged to think about in Tcl in the first place, though tcl::unsupported::representation can be helpful with probing this in 8.6 — and some very careful interlocking between the threads so that one isn't writing while the other is peeking. Don't do this at all, while not 100% accurate, is the approach least likely to lead to headaches.
You probably ought to read more about how you're supposed to do it. The ActiveState blog has a reasonable introduction.

SIGSEGV and mono crash issue while running .NET binary using mono

I have ubuntu 12.04 Linux on my PC and mono-complete package "Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2)".
I am going to run one .NET binary using mono and got SIGSEGV signal after running that binary and mono is going to be crashed after that.
I have also got some gdb debug messages on command prompt whihc i have mentioned below.
Thread 2 (Thread 0xb28ffb40 (LWP 20460)) :
#0 0xb7796424 in __kernel_vsyscall ()
#1 0xb77329db in read () from /lib/i386-linux-gnu/libpthread.so.0
#2 0x080e18e7 in read (__nbytes=1024, __buf=0xb2e0867c, __fd=<optimized out>) at /usr/include/i386-linux-gnu/bits/unistd.h:45
#3 mono_handle_native_sigsegv (signal=11, ctx=0xb2e08bcc) at mini-exceptions.c:2208
#4 0x081209fc in mono_arch_handle_altstack_exception (sigctx=0xb2e08bcc, fault_addr=0x0, stack_ovf=0) at exceptions-x86.c:1223
#5 0x0806094d in mono_sigsegv_signal_handler (_dummy=11, info=0xb2e08b4c, context=0xb2e08bcc) at mini.c:5909
#6 <signal handler called>
#7 0xb48881dc in ?? ()
#8 0xb2bcba6b in bulk_interrupt_read_thread (arguments=0xb4888108) at testusb.c:1596
#9 0xb772bd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#10 0xb766adde in clone () from /lib/i386-linux-gnu/libc.so.6
Thread 1 (Thread 0xb757a700 (LWP 20449)) :
#0 0xb7796424 in __kernel_vsyscall ()
#1 0xb765c690 in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0xb2c2c984 in ?? ()
#3 0xb2c2bdb0 in ?? ()
#4 0xb2c2e2d4 in ?? ()
#5 0xb2c4e770 in ?? ()
#6 0xb2c4b86c in ?? ()
#7 0xb2c4b527 in ?? ()
#8 0xb2e14518 in ?? ()
#9 0xb2e139a8 in ?? ()
#10 0xb2e13648 in ?? ()
#11 0xb58e3f84 in ?? ()
#12 0xb58e403e in ?? ()
#13 0x08064c2c in mono_jit_runtime_invoke (method="GTechUtility.Program:Main ()", obj=0x0, params=0xbfab491c, exc=0x0) at mini.c:5791
#14 0x081a422f in mono_runtime_invoke (method="GTechUtility.Program:Main ()", obj=0x0, params=0xbfab491c, exc=0x0) at object.c:2755
#15 0x081a7025 in mono_runtime_exec_main (method="GTechUtility.Program:Main ()", args=0x3be00, exc=0x0) at object.c:3938
#16 0x080bb80b in main_thread_handler (user_data=<synthetic pointer>) at driver.c:1003
#17 mono_main (argc=2, argv=0xbfab4ae4) at driver.c:1855
#18 0x0805998f in mono_main_with_options (argv=0xbfab4ae4, argc=2) at main.c:66
#19 main (argc=2, argv=0xbfab4ae4) at main.c:97
=================================================================
Got a SIGSEGV while executing native code.
This usually indicates a fatal error in the mono runtime or one of the native libraries used by your
application.
=================================================================
Aborted (core dumped)
Please let me know if any one have idea about this issue.
Try this: Disable increasing amounts of your own/application code until the error goes away. Then refine, with smaller steps, to see which part/line of your code is causing this.
If in the end, there is absolutely no own/application code left, play with the configuration, version, compiler options, of the libraries you're using.
Sorry I can't give you a detailed answer, but I HTH. Good luck!

How can I add debugging symbols to Audacious?

I am writing a plugin for audacious, and I am experiencing random segfaults. I looked around and I found that I can process the program's core dumps with gdb.
So I did that, and I got this output:
http://pastebin.com/m7d0d663d
As you can see, it says no debugging symbols where found anywhere. I want to compile audacious with debugging symbols, but I am not sure how. I tried editing configure, which only includes a file named buildsys.mk, so I edited that and removed the -s flag from the linker, and made sure that the -g flag is passed to the compiler. The gdb output above is after I did that, so apparently what I did had no effect.
So how can I retain debugging symbols when compiling audacious? The problem is that I am only writing a small plugin, and haven't got a grasp of the while audacious code.
UPDATE: I added debugging symbols for gtk+ and glib (and also tried the CFLAGS=-g option), and I got a couple of coredumps analyzed. The bottom line is this:
(gdb) bt
#0 gtk_text_iter_make_real (_iter=<value optimized out>) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:202
#1 0xb7c1cf5e in _gtk_text_iter_get_any_segment (iter=0x0) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:474
#2 0xb7c24cd6 in IA__gtk_text_layout_get_line_display (layout=0x93a4318, line=0x9af6270, size_only=1) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:2196
#3 0xb7c29172 in gtk_text_layout_real_wrap (layout=0x93a4318, line=0x9af6270, line_data=0xb10036b8) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:1147
#4 0xb7c2358f in IA__gtk_text_layout_wrap (layout=0x93a4318, line=0x9af6270, line_data=0x0) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:693
#5 0xb7c060a1 in _gtk_text_btree_validate_line (tree=0x9407370, line=0x9af6270, view_id=0x93a4318) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextbtree.c:5422
#6 0xb7c27dc1 in IA__gtk_text_layout_validate_yrange (layout=0x93a4318, anchor=0xbfb0e624, y0=0, y1=635) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextlayout.c:1062
#7 0xb7c34999 in gtk_text_view_validate_onscreen (text_view=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3502
#8 0xb7c35f85 in gtk_text_view_flush_first_validate (text_view=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3558
#9 0xb7c35fde in first_validate_callback (data=0x9406000) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextview.c:3577
#10 0xb79c88fb in gdk_threads_dispatch (data=0x9bce910) at /build/buildd/gtk+2.0-2.16.1/gdk/gdk.c:498
#11 0xb7e38c81 in g_idle_dispatch (source=0x938a400, callback=0, user_data=0x9bce910) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:3922
#12 0xb7e3ab88 in IA__g_main_context_dispatch (context=0x9250760) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:1814
#13 0xb7e3e0eb in g_main_context_iterate (context=0x9250760, block=1, dispatch=1, self=0x92333e8) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2448
#14 0xb7e3e5ba in IA__g_main_loop_run (loop=0x9a92c88) at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2656
#15 0xb7b707d9 in IA__gtk_main () at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c:1205
#16 0xb268d56a in skins_init () from /usr/local/lib/audacious/General/skins.so
#17 0x0805b42a in ?? ()
#18 0xb7540775 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#19 0x08055361 in ?? ()
(gdb)
And the exact error is:
#0 gtk_text_iter_make_real (_iter=<value optimized out>) at /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c:202
202 /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c: No such file or directory.
in /build/buildd/gtk+2.0-2.16.1/gtk/gtktextiter.c
The exact line is this:
if (iter->segments_changed_stamp !=
Can anyone make anything out of this? :-\
While it's true that doing either:
./configure CFLAGS=-g && make && make install
or
make CFLAGS=-g
will get you a build with debug symbols, this is quite unlikely to help you solve the problem.
You program crashed in /usr/lib/libgtk-x11-2.0.so.0, not in audacious2 (whatever that is). You are also analyzing the core incorrectly: list doesn't make sense at that stage. Your very first (gdb) command when analyzing a core should almost always be where, followed by thread apply all where.
You might also get better results from installing libgtk2-debuginfo or some such package, which should provide debug info for libgtk-x11-2.0.so.0, and may allow you to see the source and variables in libgtk at crash point.
As far as I know, audacious uses autotools. No need to modify anything, just configure with:
CFLAGS="-g $CFLAGS" ./configure
followed by the usual steps to install it. The flags are stored (in config.status I think), so any subsequent call to make will build a debug-enabled audacious.

Resources