Deadlock using gconv / iconv

[MKechlibar]

VBox 4.3.4, Guest system: openSuse 13.1 32-bit.

Any program which uses gconv library will deadlock when invoking iconv_open. Using debugger, I was able to extract the following two stacks of program threads which illustrate the problem.

Thread [1] is somehow created by VirtualBox (at least method names indicate so). Thread [15] is thread of my own program, which attempts to access gconv/iconv in order to convert strings.

Thread [1] 8308 [core: 0] (Suspended : Signal : SIGINT:Interrupt)	
	__kernel_vsyscall() at 0xb7fdc430	
	__lll_lock_wait_private() at lowlevellock.S:97 0xb77cac23	
	_L_lock_2554static pthread_mutex_t foo_mutex = PTHREAD_MUTEX_INITIALIZER;() at gconv_db.c:805 0xb76eb15b	
	__gconv_find_transform() at gconv_db.c:728 0xb76eaef6	
	__gconv_open() at gconv_open.c:172 0xb76e9957	
	iconv_open() at iconv_open.c:71 0xb76e9500	
	0xb5b6b24a	
	RTStrUtf8ToCurrentCPTag() at 0xb5b6b738	
	RTEnvGetEx() at 0xb5b7a000	
	0xb5b78421	
	RTOnceSlow() at 0xb5b80299	
	0xb5b786f8	
	0xb5b6e6e3	
	0xb5b5d876	
	0xb5b5da57	
	0xb5b5de11	
	RTR3InitDll() at 0xb5b5def2	
	0xb5b31eb3	
	0xb5b32125	
	0xb5b2272c	
	<...more frames...>	

Thread [15] 9092 [core: 0] (Suspended : Container)	
	__kernel_vsyscall() at 0xb7fdc430	
	__lll_lock_wait() at lowlevellock.S:144 0xb79f5ba9	
	_L_lock_961() at 0xb79f1467	
	__GI___pthread_mutex_lock() at pthread_mutex_lock.c:114 0xb79f12e8	
	_dl_open() at dl-open.c:602 0xb7fefad0	
	do_dlopen() at dl-libc.c:87 0xb77f56ab	
	_dl_catch_error() at dl-error.c:177 0xb7fec0ba	
	dlerror_run() at dl-libc.c:46 0xb77f579b	
	__GI___libc_dlopen_mode() at dl-libc.c:163 0xb77f5821	
	__gconv_find_shlib() at gconv_dl.c:116 0xb76f3651	
	find_module() at gconv_cache.c:195 0xb76f2d77	
	__gconv_lookup_cache() at gconv_cache.c:392 0xb76f3232	
	__gconv_find_transform() at gconv_db.c:730 0xb76eaf0f	
	__gconv_open() at gconv_open.c:172 0xb76e9957	
	iconv_open() at iconv_open.c:71 0xb76e9500	
	CCnvCharacterSetConverter::ConvertToUnicode() at charconv_unix.cpp:135 0x8a81295	
	CCnvCharacterSetConverter::ConvertToUnicode() at charconv_unix.cpp:227 0x8a81516	
	ConvertFileNameToUnicodeL() at ZipFileLight.cpp:457 0x8acd428	
	CZipFileLight::ReadCentralDirectoryHeaderL() at ZipFileLight.cpp:533 0x8acd8ac	
	CZipFileLight::LoadMemberPointersL() at ZipFileLight.cpp:386 0x8acd283	
	<...more frames...>	

[MKechlibar]

I have just recently discovered that turning off the 3D acceleration solves the problem. So the problem is only present when 3D acceleration is on. Could it have something in common with MESA drivers?

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.