From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: wrong behaviour of Date: Thu, 02 Dec 2010 10:12:13 +0100 Message-ID: <4CF762ED.2030104@swipnet.se> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1291305366 12137 80.91.229.12 (2 Dec 2010 15:56:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Dec 2010 15:56:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: alin soare Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 02 16:56:02 2010 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.69) (envelope-from ) id 1POBVp-0005hG-9T for ged-emacs-devel@m.gmane.org; Thu, 02 Dec 2010 16:56:01 +0100 Original-Received: from localhost ([127.0.0.1]:60905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POBVo-0002zD-Kt for ged-emacs-devel@m.gmane.org; Thu, 02 Dec 2010 10:56:00 -0500 Original-Received: from [140.186.70.92] (port=52541 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POAcA-00010S-L3 for emacs-devel@gnu.org; Thu, 02 Dec 2010 09:58:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PO5D7-0005T8-DF for emacs-devel@gnu.org; Thu, 02 Dec 2010 04:12:18 -0500 Original-Received: from smtprelay-b12.telenor.se ([62.127.194.21]:40539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PO5D7-0005T2-6i for emacs-devel@gnu.org; Thu, 02 Dec 2010 04:12:17 -0500 Original-Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b12.telenor.se (Postfix) with ESMTP id 6B193DBEE for ; Thu, 2 Dec 2010 10:12:15 +0100 (CET) X-SENDER-IP: [85.225.45.100] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlI1APvw9kxV4S1kPGdsb2JhbACIH5sADAEBAQE1LcF1hUcEjXc X-IronPort-AV: E=Sophos;i="4.59,287,1288566000"; d="scan'208";a="154997055" Original-Received: from c-642de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.100]) by ipb2.telenor.se with ESMTP; 02 Dec 2010 10:12:14 +0100 Original-Received: from [172.20.199.14] (zeplinf [172.20.199.14]) by coolsville.localdomain (Postfix) with ESMTPSA id 534317FA05A; Thu, 2 Dec 2010 10:12:14 +0100 (CET) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:133314 Archived-At: Read the comments: /* All Lisp_Object components must come first. That ensures they are all aligned normally. */ and /* Beyond here, there should be no more Lisp_Object components. */ Also see allocate_frame in alloc.c and make_frame in frame.c. Jan D. alin soare skrev 2010-12-02 09.54: > I defined within the struct frame an integer variable > > int ct; > > If I define it immediately after the menu_bar_vector, it is initialized > somewhere with the pointer value of Qnil. (&Qnil) > > Only the X toolkit version uses this. */ > > Lisp_Object menu_bar_vector; > + > + int ct; > > > In this case, if I change the value f->ct, emacs crashes with segmentation > fault, generated by the garbage collector. Why , as time as I initialize a > variable defined by myself ? > > > ----------------------------------------- > > If I define it at the end of struct frame, id est immediately after the > fieldforeground_pixel, > > /* All display backends seem to need these two pixel values. */ > unsigned long background_pixel; > unsigned long foreground_pixel; > + > + int ct; > } > > everything works fine in that case. > > I wish to ask you to suggest me if you can, what happens when I define the var. > 'ct' inside the struct frame. > > > > Alin. > > >