public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dtrebbien at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12091] New: gconv: Allow iconv_open to recurse Date: Sun, 03 Oct 2010 17:45:00 -0000 [thread overview] Message-ID: <20101003174522.12091.dtrebbien@gmail.com> (raw) I am working on a gconv module in which I would like to be able to call `iconv_open` within the module's `gconv_init` function. It is particularly important that my module be able to call `iconv_open` within `gconv_init` because only `gconv_init` can return an appropriate error code should `iconv_open` fail; however, the way that glibc `iconv_open` is currently programmed, calling `iconv_open` within `gconv_init` causes deadlock due to the fact that the current thread attempts to lock the non-reentrant mutex `__gconv_lock` a second time: $ gdb iconv GNU gdb (GDB) 7.2-debian Copyright (C) 2010 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 "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/iconv...Reading symbols from /usr/lib/debug/usr/bin/iconv...done. done. (gdb) break gconv_init Function "gconv_init" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (gconv_init) pending. (gdb) run -f UTF-8 -t ABC TEST.txt Starting program: /usr/bin/iconv -f UTF-8 -t ABC TEST.txt Breakpoint 1, gconv_init (step=0x8056840) at ABC.c:8 8 iconv_t cd = iconv_open("UTF-8", "ISO-8859-1"); (gdb) s iconv_open (tocode=0xb7fd75df <error reading variable>, fromcode=0xb7fd75d4 <error reading variable>) at iconv_open.c:34 34 iconv_open.c: No such file or directory. in iconv_open.c (gdb) finish Run till exit from #0 iconv_open (tocode=0xb7fd75df <error reading variable>, fromcode=0xb7fd75d4 <error reading variable>) at iconv_open.c:34 ^C Program received signal SIGINT, Interrupt. 0xb7fe2416 in __kernel_vsyscall () (gdb) bt #0 0xb7fe2416 in __kernel_vsyscall () #1 0xb7f64163 in __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:95 #2 0xb7ea452b in _L_lock_2093 () at gconv_db.c:761 #3 0xb7ea433c in __gconv_find_transform ( toset=0xbffff1c0 <error reading variable>, fromset=0xbffff1a0 <error reading variable>, handle=<value optimized out>, nsteps=0xbffff180, flags=0) at gconv_db.c:728 #4 0xb7ea2c7a in __gconv_open (toset=<value optimized out>, fromset=<value optimized out>, handle=<value optimized out>, flags=0) at gconv_open.c:174 #5 0xb7ea287c in iconv_open (tocode=0xb7fd75df <error reading variable>, fromcode=0xb7fd75d4 <error reading variable>) at iconv_open.c:72 #6 0xb7fd7526 in gconv_init (step=0x8056840) at ABC.c:8 #7 0xb7eaaf1e in find_module (directory=<value optimized out>, filename=<value optimized out>, result=0x8056840) at gconv_cache.c:217 #8 0xb7eab210 in __gconv_lookup_cache (toset=<value optimized out>, fromset=<value optimized out>, handle=<value optimized out>, nsteps=0xbffff334, flags=<value optimized out>) at gconv_cache.c:340 #9 0xb7ea4355 in __gconv_find_transform ( toset=0xbffff370 <error reading variable>, fromset=0xbffff360 <error reading variable>, handle=<value optimized out>, nsteps=0xbffff334, flags=0) at gconv_db.c:730 ---Type <return> to continue, or q <return> to quit--- #10 0xb7ea2c7a in __gconv_open (toset=<value optimized out>, fromset=<value optimized out>, handle=<value optimized out>, flags=0) at gconv_open.c:174 #11 0xb7ea287c in iconv_open (tocode=0xbffff683 <error reading variable>, fromcode=0xbffff67a <error reading variable>) at iconv_open.c:72 #12 0x0804a428 in main (argc=6, argv=0xbffff4f4) at iconv_prog.c:210 (gdb) Note: The problematic locking occurs within `__gconv_find_transform`. -- Summary: gconv: Allow iconv_open to recurse Product: glibc Version: 2.11 Status: NEW Severity: enhancement Priority: P2 Component: libc AssignedTo: drepper dot fsp at gmail dot com ReportedBy: dtrebbien at gmail dot com CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=12091 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
next reply other threads:[~2010-10-03 17:45 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-10-03 17:45 dtrebbien at gmail dot com [this message] 2010-10-03 17:52 ` [Bug libc/12091] " dtrebbien at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20101003174522.12091.dtrebbien@gmail.com \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).