From owner-freebsd-gnome@FreeBSD.ORG Sat Jan 14 19:33:57 2006 Return-Path: X-Original-To: gnome@freebsd.org Delivered-To: freebsd-gnome@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC58816A41F for ; Sat, 14 Jan 2006 19:33:57 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E02C143D4C for ; Sat, 14 Jan 2006 19:33:56 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so854764nzo for ; Sat, 14 Jan 2006 11:33:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YvKzUH7yTjOqGxsSryqrKjFJPWarLDgOtkAkNz6bcZ5vlCeQdtkoDQk128sQ7/uCE14J9G3b2Tb4zSXoEG6BGk6+HkXAZwVAidA1r9WWS/WS5HdPAbl5RN7gMbv6hsz6dzWRv/TzJBnvZu1ByCVzxKD8OM21k6Bv/iXlYhNNKX0= Received: by 10.36.101.3 with SMTP id y3mr3508008nzb; Sat, 14 Jan 2006 11:33:56 -0800 (PST) Received: by 10.36.42.9 with HTTP; Sat, 14 Jan 2006 11:33:56 -0800 (PST) Message-ID: Date: Sat, 14 Jan 2006 11:33:56 -0800 From: Pascal Hofstee To: gnome@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Evolution and jemalloc X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2006 19:33:57 -0000 After jemalloc turned out to have a distinct disliking for MC-gnome's glib-2.9.2 i opted to pkg_delete -a and install a clean standard ports-version of the Gnome-2.12.x environment. Everything is now working as expected with the sole exception so far of Evolution, which seems to generate a runaway process that eats up all available memory + swap before the kernel shoots it down. (This is with no limits on vmemory_usage set) on CURRENT/amd64. I also found that setting MALLOC_OPTIONS to aj fixes the runaway process problems and evolution starts up as expected. So far i have been able to trace program execution down to the following IDL-generated code block (and a partial back-trace to illustrate how it got to that point). The function is generated inside ${WORKDIR}/evolution-2.4 /shell/Evolution-stubs.c (iirc) void GNOME_Evolution_Component_setLineStatus(GNOME_Evolution_Component _obj= , const CORBA_boolean online, const GNOME_Evolution_Listener listener, CORBA_Environment *ev){ gpointer _args[2]; _args[0] =3D (gpointer)&online; _args[1] =3D (gpointer)&listener; ORBit_c_stub_invoke (_obj, &GNOME_Evolution_Component__iinterface.methods, 9, NULL, _args, NULL, ev, GNOME_Evolution_Component__classid, G_STRUCT_OFFSET (POA_GNOME_Evolution_Component__epv, setLineStatus), (ORBitSmallSkeleton) _ORBIT_skel_small_GNOME_Evolution_Component_setLineStatus); } #0 GNOME_Evolution_Component_setLineStatus (_obj=3D0x809179980, online=3D1 '\001', listener=3D0x8092194f0, ev=3D0x7fffffffe3d0) at Evolution-stubs.c:84 _args =3D {0x7fffffffe3af, 0x7fffffffe3a0} #1 0x00000000004154f8 in set_line_status (shell=3D0x80908ef80, status=3D1)= at e-shell.c:1147 info =3D (EComponentInfo *) 0x8091beec0 priv =3D (EShellPrivate *) 0x809218b50 p =3D (GSList *) 0x8090c67f0 ev =3D {_id =3D 0x0, _major =3D 0, _any =3D {_type =3D 0x0, _value = =3D 0x0, _release =3D 0 '\0'}} client =3D (GConfClient *) 0x8091beec0 #2 0x000000000041574f in e_shell_go_online (shell=3D0x80908ef80, action_window=3D0x0) at e-shell.c:1193 __PRETTY_FUNCTION__ =3D "e_shell_go_online" #3 0x000000000041488d in e_shell_construct (shell=3D0x80908ef80, iid=3D0x4= 1b8f0 "OAFIID:GNOME_Evolution_Shell:2.4", startup_line_mode=3DE_SHELL_STARTUP_LINE_MODE_CONFIG) at e-shell.c:700 priv =3D (EShellPrivate *) 0x1 corba_object =3D 0x1 start_online =3D 1 __PRETTY_FUNCTION__ =3D "e_shell_construct" The offending line as far as i have been able to trace it down is the ORBit_c_stub_invoke call in the code above. If anyone could help me further tracing down this issue and tell me what i should likely have a look at that would be highly appreciated .. as i am getting kinda stuck on my debugging at this point. -- Pascal Hofstee