Can I comment on this? Heck of yeah. that's like asking me if I have an opinion!!! :)
Reviewing you other recent post about arserverd crashing while trying to start, your stack trace looked like this: Stacks: /prod/sys/remedyb/bin/arserverd:DumpStackTrace+0x88 /prod/sys/remedyb/bin/arserverd:SignalTrapProc+0x160 /usr/lib/libthread.so.1:0x15bac /usr/lib/libthread.so.1:0xf804 /usr/lib/libthread.so.1:0xf9b4 /usr/lib/libc.so.1:0x4762c [ Signal 11 (SEGV)] /usr/lib/libc.so.1:0x47100 /usr/lib/libc.so.1:malloc+0x20 /prod/sys/remedyb/bin/arserverd:MallocLob+0x110 /prod/sys/remedyb/bin/arserverd:LoadFieldIntoValue+0x428 /prod/sys/remedyb/bin/arserverd:LoadDisplayInfoList+0x46c /prod/sys/remedyb/bin/arserverd:LoadInitialSchemaInfo+0x5d0 /prod/sys/remedyb/bin/arserverd:InitializeServerCache+0xec /prod/sys/remedyb/bin/arserverd:WorkerThread+0x230 /prod/sys/remedyb/bin/arserverd:RestartableThreadMain+0x60 /prod/sys/remedyb/bin/arserverd:UnixThreadStartRoutine+0xe8 /usr/lib/libthread.so.1:0x15854 The above stack tells me the actual location of the segmentation violation ( SEGV) actually occured in libc.so's malloc call. ( See 'man malloc' for documentation). You'll know malloc() only accepts 1 parameter, and it technically can't be wrong, or be able to cause a crash in and of itself since it's simply a size. When we see crashes like this, we'll usually see that lower in the malloc portion located in SUN's libc code, malloc will call subroutines like (real_malloc and real_free). Free routine when we're malloc'ing you might ask?????? Yup. SUN, and other platform memory managers, can decide to merge free blocks just about any ole time, even when you're allocating memory. If you're free heap is corrupted at all, by some previous operation, you could end up seeing a crash in malloc. Additionally, God forbid, SUN might have a defect in their memory manager that can cause the corruption and/or the SEGV directly. By leveraging libumem via LD_PRELOAD, you're instructing the SUN process loader to utilize libumem's version of malloc/realloc/calloc/free ... you can see where I'm going with this, right????? So, what you have appears to be a crash as a reulst of a corrupted heap. libumem may work around the problem wither due to a completely different layout scheme, thru protective headers, or it may work-around an inherant deffect in libc/malloc. There! you sorry you ask me to comment yet!?!?!? :) Bob --- ----- Original Message ---- From: Axton <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, October 25, 2006 2:10:42 PM Subject: Re: ARS 7.0.01 Release Notes (English) Bob: Maybe you can comment on this, because I am stumped at this point. When starting arserverd without libumem in the LD_PRELOAD, arserverd crashes with the following output: $ arserverd -s rm00d70b -i /prod/sys/remedyb -l /etc/arsystem/rm00d70b server: locale=[[ en_US.UTF-8 ]], LANG=[[ en_US.UTF-8 ]]NLS_LANG=[[ american_america.AL32UTF8 ]] Action Request System(R) Server Version 7.0.01 200609271856 Copyright (c) 1991 - 2006 BMC Software, Inc. All rights reserved. 390600 : AR System server terminated when a signal/exception was received by the server (ARNOTE 20) 11 Timestamp: Wed Oct 25 2006 15:22:51.4380 Thread Id: 4 Version: 7.0.01 200609271856 Sep 27 2006 19:28:30 ServerName: rm00d70b Database: SQL -- Oracle Hardware: sun4u OS: SunOS 5.9 RPC Id: 0 RPC Call: 0 RPC Queue: 390600 Protocol Version: 12 Client IP Address: Logging On: User When started with libumem, arserverd is able to start: $ arserverd -s rm00d70b -i /prod/sys/remedyb -l /etc/arsystem/rm00d70b server: locale=[[ en_US.UTF-8 ]], LANG=[[ en_US.UTF-8 ]]NLS_LANG=[[ american_america.AL32UTF8 ]] Action Request System(R) Server Version 7.0.01 200609271856 Copyright (c) 1991 - 2006 BMC Software, Inc. All rights reserved. Action Request System(R) Fork Daemon Version 7.0.01 200609271856 Copyright (c) 2000 - 2006 BMC Software, Inc. All rights reserved. The env vars I am setting to 'enable' libumem are: UMEM_LOGGING=transaction UMEM_DEBUG=default LD_PRELOAD=libumem.so.1 My question is this, what would libumem cause to happen that would prevent a SEGV from happening that otherwise happens? All env vars are the same in the above two examples with the exception of the three libumem related env vars. I am attempting to get a core from the crash to send to BMC but I can't because loading libumem prevents the crash. Axton Grams On 10/25/06, Bob Weiman <[EMAIL PROTECTED]> wrote: > SUN's libumem, alternative Memory manage > <from inside BMC/ARS Support> > > SUN's libumem, alternative Memory manager has several advantages over the > default SUN memory manager found in libc. The most important of which is > performance. It scales much, much better on multi-CPU SUN boxes than the > default. > > It also includes some statistical/usage data of the process heap that work > pretty good to assist in memory related issues, as well as troubleshooting > "switches" than can be deployed for those rough issues that cause process > crashes like string overwrites, double-frees and even memory leakage. > > In some cases, libumem may cause arserverd to utilize more memory than the > default memory manager. But we find the performance gains and diagnostic > functionalities to be a much better trade-off for this additional memory. > > In order to leverage libumem, you must LD_PRELOAD the library. It is > currently mentioned in BMC KB article KM-000000020267. I am currently > writing an updated version with greater libumem detail. > > Bob --- > > > > ----- Original Message ---- > From: Axton <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, October 25, 2006 10:05:05 AM > Subject: Re: ARS 7.0.01 Release Notes (English) > > > The libumem library changes are interesting. There is no longer a > debug build with 7.0.01, instead you preload libumem.so. Makes it > much easier to get core/memory info for tickets that require it. > > Axton Grams > > On 10/25/06, Tony Worthington <[EMAIL PROTECTED]> wrote: > > So the "real version" still isn't posted on supportweb, but there is a > > version bundled in with the 7.0.01 upgrade download docs zip file (which > > references the nonexistent supportweb version) > > > > What?s new in AR System 7.0.01 > > > > The following features were added in AR System 7.0.01. (This version also > > consists of defects fixed since 7.0 and includes all patches in the AR > > System code line up to the present time.) > > > > Note: For detailed descriptions of these features, see Appendix B, ?New > > features in AR System 7.0.01,? in the web version of the release notes at > > http://supportweb.remedy.com. > > > > ! Ability to install AR System with a predefined Oracle tablespace > > ! Replacement of ServletExec with Apache Tomcat in BMC Remedy Mid Tier > > ! New installation locations for the Apache Tomcat servlet container > > ! On UNIX?/usr/ar/apache-tomcat-5.5.17 > > ! On Windows?C:\Program Files\Apache Software Foundation\Tomcat 5.5 > > ! Ability to configure single sign-on using BMC Web Access Manager > > ! Support for chatr utility and libumem library > > ! Portlets for a JSR 168-compliant portal server > > ! Web services basic authentication (If you use the Set Fields action to > > consume a web service, you can provide the user name and password that the > > remote web server requires for basic authentication.) > > ! Platform cache memory improvements > > ! Updated SQL log file (The log file includes the end time after each > > transaction that is logged.) > > ! IP address change no longer requiring new login > > ! Unicode upgrade > > ! Ability to add attribute name to buttons with images (This feature > > provides alternate text required for accessibility.) > > ! Email body variable for status templates (This helps administrators > > troubleshoot failed email requests for submit, modify, and query actions; > > the variable includes the original email body in error messages.) > > ! Updated Flashboards color palette > > ! Compliant for 2007 Daylight Savings Time changes for the United States > > > > -tony > > > > -- > > Tony Worthington > > [EMAIL PROTECTED] > > 262-703-5911 > > > > CONFIDENTIALITY NOTICE: > > This is a transmission from Kohl's Department Stores, Inc. > > and may contain information which is confidential and proprietary. > > If you are not the addressee, any disclosure, copying or distribution or > > use of the contents of this message is expressly prohibited. > > If you have received this transmission in error, please destroy it and > > notify us immediately at 262-703-7000. > > > > CAUTION: > > Internet and e-mail communications are Kohl's property and Kohl's reserves > > the right to retrieve and read any message created, sent and received. > > Kohl's reserves the right to monitor messages to or from authorized Kohl's > > Associates at any time > > without any further consent. > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
