From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: strings referred to by Vsjis_coding_system, Vbig5_coding_system Date: Mon, 16 Nov 2009 07:00:20 -0800 (PST) Message-ID: <200911161500.nAGF0KYN015109@godzilla.ics.uci.edu> References: <200911112142.nABLgZwS024554@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258383752 19118 80.91.229.12 (16 Nov 2009 15:02:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Nov 2009 15:02:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 16 16:02:19 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NA35m-0001Y0-91 for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2009 16:02:10 +0100 Original-Received: from localhost ([127.0.0.1]:54659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NA35l-0002iN-Po for ged-emacs-devel@m.gmane.org; Mon, 16 Nov 2009 10:02:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NA35g-0002i1-2f for emacs-devel@gnu.org; Mon, 16 Nov 2009 10:02:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NA35b-0002eT-6Q for emacs-devel@gnu.org; Mon, 16 Nov 2009 10:02:03 -0500 Original-Received: from [199.232.76.173] (port=45699 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NA35a-0002eQ-U5 for emacs-devel@gnu.org; Mon, 16 Nov 2009 10:01:58 -0500 Original-Received: from paul-mcgann-v0.ics.uci.edu ([128.195.1.147]:42048) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NA35a-0002FP-7Z for emacs-devel@gnu.org; Mon, 16 Nov 2009 10:01:58 -0500 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by paul-mcgann-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id nAGF0KQa018030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2009 07:00:20 -0800 Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id nAGF0KYN015109; Mon, 16 Nov 2009 07:00:20 -0800 (PST) In-Reply-To: (Kenichi Handa's message of "Mon, 16 Nov 2009 22:01:06 +0900") Original-Lines: 83 X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information X-ICS-MailScanner-ID: nAGF0KQa018030 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.901, required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_BG 0.08, TW_BJ 0.08, TW_BP 0.08, TW_BX 0.08, TW_GT 0.08, TW_IB 0.08, TW_XC 0.08) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:117037 Kenichi Handa writes: > In article <200911112142.nABLgZwS024554@godzilla.ics.uci.edu>, Dan Nico= laescu writes: >=20 > > Handa-san, > > Strings like this: >=20 > > =C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF=C3= =BF=C3=BF=C3=BF=C3=BF=C3=BF=C3=BF >=20 > > are found in the GC memory in emacs, they are referred to by > > Vsjis_coding_system, Vbig5_coding_system, and maybe other variables. >=20 > > Is there any chance that such strings can be put in pure memory? > > Not sure where they are created, and what they do... >=20 > I have no idea. Are you sure that those variables refer > that string? According to the following gdb session, at > least Vbig5_coding_system doesn't refer such a string > directly. >=20 I can't find one at the moment, and unfortunately I did not save a debugging session. All the ones that I find at the moment are referred to from Vcoding_system_= hash_table. Can you please figure out this one? [Note that I have some instrumentation code in alloc.c, so the line number will not match, but none of the semantics are changed] Breakpoint 3, mark_object (arg=3D0x84d8e99) at alloc.c:5538 5538 MARK_STRING (ptr); Missing separate debuginfos, use: debuginfo-install alsa-lib-1.0.21-3.fc11.= i586 atk-1.25.2-2.fc11.i586 bzip2-libs-1.0.5-5.fc11.i586 cairo-1.8.8-1.fc11= .i586 dbus-libs-1.2.12-2.fc11.i586 e2fsprogs-libs-1.41.4-12.fc11.i586 expat= -2.0.1-6.fc11.1.i586 fontconfig-2.7.1-1.fc11.i586 freetype-2.3.9-5.fc11.i58= 6 giflib-4.1.6-2.fc11.i586 glib2-2.20.5-1.fc11.i586 glibc-2.10.1-5.i686 gpm= -libs-1.20.6-3.fc11.i586 gtk-nodoka-engine-0.7.2-5.fc11.i586 gtk2-2.16.6-2.= fc11.i586 libICE-1.0.4-7.fc11.i586 libSM-1.1.0-4.fc11.i586 libX11-1.2.2-1.f= c11.i586 libXau-1.0.4-5.fc11.i586 libXcomposite-0.4.0-7.fc11.i586 libXcurso= r-1.1.9-4.fc11.i586 libXdamage-1.1.1-6.fc11.i586 libXext-1.0.99.1-3.fc11.i5= 86 libXfixes-4.0.3-5.fc11.i586 libXft-2.1.13-2.fc11.i586 libXi-1.2.1-1.fc11= .i586 libXinerama-1.0.3-4.fc11.i586 libXpm-3.5.7-5.fc11.i586 libXrandr-1.2.= 99.4-3.fc11.i586 libXrender-0.9.4-5.fc11.i586 libattr-2.4.43-3.fc11.i586 li= bcap-2.16-4.fc11.1.i586 libcroco-0.6.2-2.fc11.i586 libgsf-1.14.11-3.fc11.i5= 86 libjpeg-6b-45.fc11.i586 libpng-1.2.37-1.fc11.i586 librsvg2-2.26.0-1.fc11= .i586 libselinux-2.0.80-1.fc11.i586 libtiff-3.8.2-14.fc11.i586 libxcb-1.2-4= .fc11.i586 libxml2-2.7.6-1.fc11.i586 ncurses-libs-5.7-2.20090207.fc11.i586 = pango-1.24.5-1.fc11.i586 pixman-0.14.0-2.fc11.i586 zlib-1.2.3-22.fc11.i586 (gdb) pp arg "=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=FF=00" (gdb) up #1 0x0817c5af in mark_vectorlike (ptr=3D0x862bf10) at alloc.c:5419 5419 mark_object (ptr->contents[i]); (gdb) up #2 0x0817c974 in mark_object (arg=3D0x862bf15) at alloc.c:5640 5640 mark_vectorlike (XVECTOR (obj)); (gdb) pp arg []=0D (gdb) up #3 0x0817c5af in mark_vectorlike (ptr=3D0x8552298) at alloc.c:5419 5419 mark_object (ptr->contents[i]); (gdb) pp arg #4 0x0817c974 in mark_object (arg=3D0x855229d) at alloc.c:5640 5640 mark_vectorlike (XVECTOR (obj)); (gdb) pp arg []=0D (gdb) up #5 0x0817c5af in mark_vectorlike (ptr=3D0x864ab48) at alloc.c:5419 5419 mark_object (ptr->contents[i]); (gdb) pp arg No symbol "arg" in current context. (gdb) up #6 0x0817c974 in mark_object (arg=3D0x864ab4d) at alloc.c:5640 5640 mark_vectorlike (XVECTOR (obj)); (gdb) pp arg []=0D (gdb) up #7 0x0817c910 in mark_object (arg=3D0x8429f2d) at alloc.c:5629 5629 MAYBE_MARK_OBJECT (h->key_and_value); (gdb) pp arg #s(hash-table size -2147482553 test eq rehash-size 1.5 rehash-threshold 0.8= data ())=0D (gdb) up #8 0x0817be26 in Fgarbage_collect () at alloc.c:5108 5108 mark_object (*staticvec[i]); (gdb) p i $1 =3D 0x1a4 0x1a4 in staticvec corresponds to Vcoding_system_hash_table. > By the way, I've just found that "pr" command doesn't work > with the latest code: >=20 > (gdb) p Vbig5_coding_system > $1 =3D 139728474 > (gdb) pr > Cannot access memory at address 0x842e030 I've found many instances where "pr" crashes the debugger...