From rcrit at greyoak.com Thu Apr 8 14:55:22 2004 From: rcrit at greyoak.com (Rob Crittenden) Date: Thu, 8 Apr 2004 14:55:22 -0400 (EDT) Subject: script patch Message-ID: Hi. I was working on a multi-cd installer that uses a script to copy some of the files from the cds. The environment variable SETUP_CDROMPATH wasn't always being set because the installer always outputs the top of the cdrom list. So when you're on cd 2 it tries to print the mount point for cd 1 which is NULL when you're working on cd2. I added a cdromid attribute to the script command so one can say which cdrom the script is operating against. So if a cdromid attrbute exists I save a pointer to the head of the list, then seek to cdromid in the cdrom list, then call the script and finally restore the pointer when the script exits. While I was at it I added 2 more attributes: size and message. Size lets you indicate the amount of data that the script installs itself. Message lets you replace the "Running script" message with something slightly more useful to the end-user. The installer I was working on used Microsoft cabinet files. Rather than porting cabextract to a setup plugin I call it from a shell script instead. Since the majority (90%) of the files are in .cab files the total installed progress bar was about 5% during 95% of the installation. So instead with the size message at the end of each installation script the total progress goes up a bit. A sample entry looks like: I wasn't sure where to submit this so I figured I'd start here rather than bugging Ryan about it, he seems busy enough. rob -------------- next part -------------- Index: copy.c =================================================================== RCS file: /cvs/cvsroot/loki_setup/copy.c,v retrieving revision 1.74 diff -u -r1.74 copy.c --- copy.c 1 Mar 2004 06:29:42 -0000 1.74 +++ copy.c 8 Apr 2004 18:39:13 -0000 @@ -729,16 +729,36 @@ } int copy_script(install_info *info, xmlNodePtr node, const char *script, const char *dest, - int (*update)(install_info *info, const char *path, size_t progress, size_t size, const char *current)) + int (*update)(install_info *info, const char *path, size_t progress, size_t size, const char *current), const char *from_cdrom, const char *msg) { + struct cdrom_elem *cdrom; + struct cdrom_elem *cdrom_start; + int rc; + if ( corrupts ) { /* Don't run any scripts while restoring files */ return 0; } if ( update ) { - if ( ! update(info, _("Running script"), 0, 0, current_option_txt) ) + if (msg != NULL) + rc = update(info, msg, 0, 0, current_option_txt); + else + rc = update(info, _("Running script"), 0, 0, current_option_txt); + if ( !rc ) return 0; } - return(run_script(info, script, -1, 1)); + + cdrom_start = info->cdroms_list; + while ( from_cdrom != NULL && info->cdroms_list ) { + cdrom = info->cdroms_list; + if (!strcmp(cdrom->id, from_cdrom)) { + break; + } + info->cdroms_list = cdrom->next; + } + + rc = run_script(info, script, -1, 1); + info->cdroms_list = cdrom_start; + return rc; } ssize_t copy_node(install_info *info, xmlNodePtr node, const char *dest, @@ -819,9 +839,16 @@ size += copied; } } else if ( strcmp(node->name, "script") == 0 ) { - copy_script(info, node, + const char *sz= xmlGetProp(node, "size"); + const char *msg= xmlGetProp(node, "message"); + int rc; + rc = copy_script(info, node, xmlNodeListGetString(info->config, node->childs, 1), - path, update); + path, update, from_cdrom, msg); + if (rc == 0 && sz) { + info->installed_bytes += atoi(sz); + size += atoi(sz); + } } } /* Do not handle exclusive elements here; it gets called multiple times else */ Index: README.xml =================================================================== RCS file: /cvs/cvsroot/loki_setup/README.xml,v retrieving revision 1.57 diff -u -r1.57 README.xml --- README.xml 18 Feb 2004 03:56:55 -0000 1.57 +++ README.xml 8 Apr 2004 18:39:16 -0000 @@ -760,6 +760,18 @@ string of this attribute. See 'About localization' below for more details. + size If the script handles the installation of some files and you want + the progress bar to reflect it, indicate the size here. The size + is updated when the script finishes. The unit is in bytes. + + message The message to display to the user. By default this is + "Running script" + + cdromid When doing a multi-cd installation and running scripts then + SETUP_CDROMPATH may not be set as expected. To ensure that it is + set properly indicate which CD the script is executing against + if it is copying files from a CD. + It is also possible to filter the scripts on system characteristics, through the use of the "arch", "glibc" and "distro" attributes, that work just like for the "files" element. From megastep at megastep.org Thu Apr 8 19:00:56 2004 From: megastep at megastep.org (Stephane Peter) Date: Thu, 8 Apr 2004 16:00:56 -0700 Subject: [lokisetup] script patch In-Reply-To: References: Message-ID: <9813AAF6-89B0-11D8-B5B6-000A959DD562@megastep.org> Hi Rob, Thanks for your patch - I'm looking at it and will probably merge parts if not all of it in the main CVS tree. You may want to contact me directly in the future for patch submissions, too. I'm maintaining loki_setup at the moment, though Ryan is an occasional contributor, as you know he is very busy ;-) On Apr 8, 2004, at 11:55 AM, Rob Crittenden wrote: > Hi. > > I was working on a multi-cd installer that uses a script to copy some > of > the files from the cds. The environment variable SETUP_CDROMPATH wasn't > always being set because the installer always outputs the top of the > cdrom > list. So when you're on cd 2 it tries to print the mount point for cd 1 > which is NULL when you're working on cd2. > > I added a cdromid attribute to the script command so one can say which > cdrom the script is operating against. So if a cdromid attrbute exists > I save a pointer to the head of the list, then seek to cdromid in the > cdrom list, then call the script and finally restore the pointer when > the > script exits. > > While I was at it I added 2 more attributes: size and message. > > Size lets you indicate the amount of data that the script installs > itself. > > Message lets you replace the "Running script" message with something > slightly > more useful to the end-user. > > The installer I was working on used Microsoft cabinet files. Rather > than > porting cabextract to a setup plugin I call it from a shell script > instead. > Since the majority (90%) of the files are in .cab files the total > installed > progress bar was about 5% during 95% of the installation. So instead > with > the size message at the end of each installation script the total > progress > goes up a bit. > > A sample entry looks like: > > > > I wasn't sure where to submit this so I figured I'd start here rather > than > bugging Ryan about it, he seems busy enough. > > rob > -- St?phane Peter megastep at megastep.org From archlyn at comcast.net Mon Apr 12 20:45:07 2004 From: archlyn at comcast.net (Robert Townsand) Date: Mon, 12 Apr 2004 20:45:07 -0400 Subject: UT2003 troubles Message-ID: <407B3813.30709@comcast.net> I'm not entirely sure if this is the proper place for this, but I need help. I've intalled UT2003 in windows. Works like a dream. If I use those same disks in Linux, I get the following error, on a random file: failed to uncompress file. ./setup.sh: line 214: 19848 Aborted "$setup" "$@" ./setup.sh: line 214: 24167 Segmentation fault "$setup" "$@" The setup program seems to have failed on x86/glibc-2.1 I've asked this on several linux BBs, googled for it, but still have no answer. System specs: AMD Athlon XP 2400+ 512MBs RAM GF4 TI 4200 SBLive 5.1 Slackware-current (updated regularly by swaret) w/ kernel 2.6.5 Any ideas? From relic2k at canada.com Tue Apr 13 05:37:33 2004 From: relic2k at canada.com (relic2k at canada.com) Date: Tue, 13 Apr 2004 02:37:33 -0700 (PDT) Subject: [lokisetup] UT2003 troubles Message-ID: <20040413023734.26716.h021.c009.wm@mail.canada.com.criticalpath.net> On Mon, 12 Apr 2004 20:45:07 -0400, Robert Townsand wrote: > > I'm not entirely sure if this is the proper place for > this, but I need > help. I've intalled UT2003 in windows. Works like a > dream. If I use > those same disks in Linux, I get the following error, > on a random file: > > failed to uncompress file. > ./setup.sh: line 214: 19848 Aborted > "$setup" "$@" > ./setup.sh: line 214: 24167 Segmentation fault > "$setup" "$@" > The setup program seems to have failed on x86/glibc-2.1 > > I've asked this on several linux BBs, googled for it, > but still have no > answer. > > System specs: > AMD Athlon XP 2400+ > 512MBs RAM > GF4 TI 4200 > SBLive 5.1 > Slackware-current (updated regularly by swaret) w/ > kernel 2.6.5 > > Any ideas? I too started having this problem as of yesterday. I am also not able to update via Loki Update. It errors out complaining about the newer Glibc 2.3.3 TLS verion that comes with MDL 10.0. I am wondering if perhaps my UT2003 CDs are getting corrupted from an installations that I have been doing to get the game updated properly and trying to figure out how to get UT2003 updated to the proper version with out it giving me an error all the time. I need to get my game patched so that I can work on my own MOD installers that I have created for UT2003. This is just a thought but perhaps your CD's are going corrupt too. Perhaps you should make back up copies before anything gets worse. From relic2k at canada.com Tue Apr 13 05:37:33 2004 From: relic2k at canada.com (relic2k at canada.com) Date: Tue, 13 Apr 2004 02:37:33 -0700 (PDT) Subject: [lokisetup] UT2003 troubles Message-ID: <20040413023734.26716.h021.c009.wm@mail.canada.com.criticalpath.net> On Mon, 12 Apr 2004 20:45:07 -0400, Robert Townsand wrote: > > I'm not entirely sure if this is the proper place for > this, but I need > help. I've intalled UT2003 in windows. Works like a > dream. If I use > those same disks in Linux, I get the following error, > on a random file: > > failed to uncompress file. > ./setup.sh: line 214: 19848 Aborted > "$setup" "$@" > ./setup.sh: line 214: 24167 Segmentation fault > "$setup" "$@" > The setup program seems to have failed on x86/glibc-2.1 > > I've asked this on several linux BBs, googled for it, > but still have no > answer. > > System specs: > AMD Athlon XP 2400+ > 512MBs RAM > GF4 TI 4200 > SBLive 5.1 > Slackware-current (updated regularly by swaret) w/ > kernel 2.6.5 > > Any ideas? I too started having this problem as of yesterday. I am also not able to update via Loki Update. It errors out complaining about the newer Glibc 2.3.3 TLS verion that comes with MDL 10.0. I am wondering if perhaps my UT2003 CDs are getting corrupted from an installations that I have been doing to get the game updated properly and trying to figure out how to get UT2003 updated to the proper version with out it giving me an error all the time. I need to get my game patched so that I can work on my own MOD installers that I have created for UT2003. This is just a thought but perhaps your CD's are going corrupt too. Perhaps you should make back up copies before anything gets worse. From archlyn at comcast.net Tue Apr 13 18:10:26 2004 From: archlyn at comcast.net (Robert Townsand) Date: Tue, 13 Apr 2004 18:10:26 -0400 Subject: Deus Ex 1? Message-ID: <407C6552.6050507@comcast.net> Hello again. I finally got UT2003 working again. Turns out it was a bad disc >:( I re-burned it and the game installed just fine :) Now onto my question: I was poking around Loki's site and noticed that Deus Ex 1 was "in development" Was it ever released to the public? If so, can it be legally downloaded? From chunky at icculus.org Tue Apr 13 18:33:01 2004 From: chunky at icculus.org (Chunky Kibbles) Date: Tue, 13 Apr 2004 18:33:01 -0400 Subject: [lokisetup] Deus Ex 1? In-Reply-To: <407C6552.6050507@comcast.net> References: <407C6552.6050507@comcast.net> Message-ID: <20040413223301.GC16880@gamehenge.icculus.org> On Tue, Apr 13, 2004 at 06:10:26PM -0400, Robert Townsand wrote: > Hello again. I finally got UT2003 working again. Turns out it was a bad > disc >:( I re-burned it and the game installed just fine :) Last I checked, ut2k3 wasn't an exercise in CDs you can legally burn. > Now onto my question: > I was poking around Loki's site and noticed that Deus Ex 1 was "in > development" > > Was it ever released to the public? If so, can it be legally downloaded? No, and no. Doubly so since you're a warez monkey. Sorry, Gary (-; From zakk at timedoctor.org Tue Apr 13 18:34:30 2004 From: zakk at timedoctor.org (Zachary J. Slater) Date: Tue, 13 Apr 2004 15:34:30 -0700 Subject: [lokisetup] Deus Ex 1? In-Reply-To: <407C6552.6050507@comcast.net> References: <407C6552.6050507@comcast.net> Message-ID: <20040413223429.GA28566@timedoctor.org> With regard to Deus Ex 1: No and No. -- -Zachary J. Slater zakk at timedoctor.org From ludwig.nussel at gmx.de Sat Apr 17 12:53:00 2004 From: ludwig.nussel at gmx.de (Ludwig Nussel) Date: Sat, 17 Apr 2004 18:53:00 +0200 Subject: [PATCH] uninstall.c broken Message-ID: <20040417165300.GA13929@defiant.wachendorf.lan> Hi, loki_uninstall doesn't compile. Fix: Index: loki_setup/uninstall.c =================================================================== --- loki_setup.orig/uninstall.c 2004-04-17 18:09:14.000000000 +0200 +++ loki_setup/uninstall.c 2004-04-17 18:33:16.149849255 +0200 @@ -49,7 +49,7 @@ " -v | --version : Get version information.\n" " product [component] : Uninstalls the specified product, or its subcomponent.\n" " product < -l | --list > : List installed subcomponents of product.\n" - ), argv[0]); + ), argv0); } static void log_file(const char *name, const char *reason) cu Ludwig -- (o_ Ludwig.Nussel at gmx.de //\ PGP Key ID: FF8135CE V_/_ ICQ: 52166811 From ludwig.nussel at gmx.de Sat Apr 17 15:34:42 2004 From: ludwig.nussel at gmx.de (Ludwig Nussel) Date: Sat, 17 Apr 2004 21:34:42 +0200 Subject: [PATCH] subfs Message-ID: <20040417193442.GA1862@defiant.wachendorf.lan> Hi, SUSE 9.1 uses subfs to automatically mount removable media. Unfortunately subfs mounted CD-ROMs don't appear in /etc/mtab so loki-setup doesn't find them. A subfs line in /etc/fstab looks like this: /dev/cdrom /media/cdrom subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 ut2004 installation works with the following patch: Index: loki_setup/detect.c =================================================================== --- loki_setup.orig/detect.c 2004-04-17 18:27:01.456734874 +0200 +++ loki_setup/detect.c 2004-04-17 18:27:12.427395593 +0200 @@ -580,17 +580,20 @@ mountfp = setmntent(MOUNTS_FILE, "r" ); if( mountfp != NULL ) { while( (mntent = getmntent( mountfp )) != NULL && num_cdroms < SETUP_MAX_DRIVES){ - char *tmp, mntdev[1024], mnt_type[32]; + char *tmp, mntdev[1024], mnt_type[1024]; if ( strncmp(mntent->mnt_fsname, DEVICE_FLOPPY, strlen(DEVICE_FLOPPY)) == 0) continue; - strcpy(mntdev, mntent->mnt_fsname); - strcpy(mnt_type, mntent->mnt_type); +#define XXXstrcpy(d,s) \ + do { strncpy(d,s,sizeof(d)); d[sizeof(d)-1] = '\0'; } while(0); + + XXXstrcpy(mntdev, mntent->mnt_fsname); + XXXstrcpy(mnt_type, mntent->mnt_type); if ( strcmp(mnt_type, MNTTYPE_SUPER) == 0 ) { tmp = strstr(mntent->mnt_opts, "fs="); if ( tmp ) { - strcpy(mnt_type, tmp+strlen("fs=")); + XXXstrcpy(mnt_type, tmp+strlen("fs=")); tmp = strchr(mnt_type, ','); if ( tmp ) { *tmp = '\0'; @@ -598,7 +601,7 @@ } tmp = strstr(mntent->mnt_opts, "dev="); if ( tmp ) { - strcpy(mntdev, tmp+strlen("dev=")); + XXXstrcpy(mntdev, tmp+strlen("dev=")); tmp = strchr(mntdev, ','); if ( tmp ) { *tmp = '\0'; @@ -606,14 +609,28 @@ } } + if ( strcmp(mnt_type, "subfs") == 0 ) { + tmp = strstr(mntent->mnt_opts, "fs="); + if ( tmp ) { + XXXstrcpy(mnt_type, tmp+strlen("fs=")); + tmp = strchr(mnt_type, ','); + if ( tmp ) { + *tmp = '\0'; + } + } + if(!strcmp(mnt_type, "cdfss")) + XXXstrcpy(mnt_type, MNTTYPE_CDROM); + } + tmp = strstr(mntent->mnt_opts, "loop="); if ( tmp ) { - strcpy(mntdev, tmp+strlen("loop=")); + XXXstrcpy(mntdev, tmp+strlen("loop=")); tmp = strchr(mntdev, ','); if ( tmp ) { *tmp = '\0'; } } +#undef XXXstrcpy if( strncmp(mntdev, "/dev", 4) || realpath(mntdev, mntdevpath) == NULL ) { cu Ludwig -- (o_ Ludwig.Nussel at gmx.de //\ PGP Key ID: FF8135CE V_/_ ICQ: 52166811 From ludwig.nussel at gmx.de Sat Apr 17 15:42:34 2004 From: ludwig.nussel at gmx.de (Ludwig Nussel) Date: Sat, 17 Apr 2004 21:42:34 +0200 Subject: [PATCH] freeing the product info Message-ID: <20040417194234.GB1862@defiant.wachendorf.lan> Hi, Handling of info->product is broken. It just can't work if you assign something to info->product, free it and then try to access it. That happens for example when installers have post install scripts. Since info->product ist created in create_install(), I propose to free it in delete_install() instead of generate_uninstall(). I tested the component install and uninstall with Rune HoV, worked fine with the patch. Index: loki_setup/install.c =================================================================== --- loki_setup.orig/install.c 2004-04-17 19:31:46.553443982 +0200 +++ loki_setup/install.c 2004-04-17 19:48:33.033714876 +0200 @@ -1410,6 +1410,12 @@ free(comp->message); free(comp); } + if(info->product) + { + loki_closeproduct(info->product); + info->product = NULL; + } + delete_cdrom_install(info); if ( info->lookup ) { close_lookup(info->lookup); @@ -1763,10 +1769,8 @@ product_option_t *option; struct component_elem *comp; - if ( info->component ) { /* Component install, the product has already been opened */ - product = info->product; - component = info->component; - } else { + if(!info->product) { + log_debug("create new product"); /* Try to open the product first in case it was installed previously */ product = loki_openproduct(info->name); if ( ! product ) { @@ -1779,6 +1783,9 @@ info->product = product; } + product = info->product; + component = info->component; + if ( product ) { char buf[PATH_MAX]; struct envvar_elem *var; @@ -1951,8 +1958,6 @@ snprintf(buf, sizeof(buf), "setup.data/bin/%s/%s/uninstall", detect_os(), detect_arch()); loki_upgrade_uninstall(product, buf, "setup.data/locale"); - /* We must call the following in all cases - component installs even, as we have to save the changes */ - loki_closeproduct(product); } else { log_fatal(_("Could not create install log"), detect_home(), info->name); cu Ludwig -- (o_ Ludwig.Nussel at gmx.de //\ PGP Key ID: FF8135CE V_/_ ICQ: 52166811 From megastep at megastep.org Sat Apr 17 20:11:18 2004 From: megastep at megastep.org (=?ISO-8859-1?Q?St=E9phane?= Peter) Date: Sat, 17 Apr 2004 17:11:18 -0700 Subject: [lokisetup] [PATCH] subfs In-Reply-To: <20040417193442.GA1862@defiant.wachendorf.lan> References: <20040417193442.GA1862@defiant.wachendorf.lan> Message-ID: <1082247078.3104.11.camel@megaserv.megastep-la.org> Cool :) I'm committing this patch as well as the previous one that fixed the uninstall.c compilatio. > Hi, > > SUSE 9.1 uses subfs to automatically mount removable media. > Unfortunately subfs mounted CD-ROMs don't appear in /etc/mtab so > loki-setup doesn't find them. A subfs line in /etc/fstab looks like > this: > > /dev/cdrom /media/cdrom subfs fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0 > > ut2004 installation works with the following patch: [...] > cu > Ludwig -- Stephane Peter Sr. Software Engineer Codehost, Inc. From megastep at megastep.org Sat Apr 17 20:20:13 2004 From: megastep at megastep.org (=?ISO-8859-1?Q?St=E9phane?= Peter) Date: Sat, 17 Apr 2004 17:20:13 -0700 Subject: [lokisetup] [PATCH] freeing the product info In-Reply-To: <20040417194234.GB1862@defiant.wachendorf.lan> References: <20040417194234.GB1862@defiant.wachendorf.lan> Message-ID: <1082247613.3104.23.camel@megaserv.megastep-la.org> I'm a bit nervous to commit this because the last patch addressing this problem actually broke component installs for me. I'll try this but I've been using the current CVS code in a commercial product with post-install scripts among a bunch of platforms with no problem so far. So I'm not sure why this wouldn't work for you ? > Hi, > > Handling of info->product is broken. It just can't work if you assign > something to info->product, free it and then try to access it. That > happens for example when installers have post install scripts. > > Since info->product ist created in create_install(), I propose to > free it in delete_install() instead of generate_uninstall(). I > tested the component install and uninstall with Rune HoV, worked > fine with the patch. > > > Index: loki_setup/install.c > =================================================================== > --- loki_setup.orig/install.c 2004-04-17 19:31:46.553443982 +0200 > +++ loki_setup/install.c 2004-04-17 19:48:33.033714876 +0200 > @@ -1410,6 +1410,12 @@ > free(comp->message); > free(comp); > } > + if(info->product) > + { > + loki_closeproduct(info->product); > + info->product = NULL; > + } > + > delete_cdrom_install(info); > if ( info->lookup ) { > close_lookup(info->lookup); > @@ -1763,10 +1769,8 @@ > product_option_t *option; > struct component_elem *comp; > > - if ( info->component ) { /* Component install, the product has already been opened */ > - product = info->product; > - component = info->component; > - } else { > + if(!info->product) { > + log_debug("create new product"); > /* Try to open the product first in case it was installed previously */ > product = loki_openproduct(info->name); > if ( ! product ) { > @@ -1779,6 +1783,9 @@ > info->product = product; > } > > + product = info->product; > + component = info->component; > + > if ( product ) { > char buf[PATH_MAX]; > struct envvar_elem *var; > @@ -1951,8 +1958,6 @@ > > snprintf(buf, sizeof(buf), "setup.data/bin/%s/%s/uninstall", detect_os(), detect_arch()); > loki_upgrade_uninstall(product, buf, "setup.data/locale"); > - /* We must call the following in all cases - component installs even, as we have to save the changes */ > - loki_closeproduct(product); > } else { > log_fatal(_("Could not create install log"), > detect_home(), info->name); > > cu > Ludwig -- Stephane Peter Sr. Software Engineer Codehost, Inc. From ludwig.nussel at gmx.de Sun Apr 18 05:53:16 2004 From: ludwig.nussel at gmx.de (Ludwig Nussel) Date: Sun, 18 Apr 2004 11:53:16 +0200 Subject: [lokisetup] [PATCH] freeing the product info In-Reply-To: <1082247613.3104.23.camel@megaserv.megastep-la.org> References: <20040417194234.GB1862@defiant.wachendorf.lan> <1082247613.3104.23.camel@megaserv.megastep-la.org> Message-ID: <20040418095316.GA4628@defiant.wachendorf.lan> St?phane Peter wrote: > I'm a bit nervous to commit this because the last patch addressing this > problem actually broke component installs for me. I'll try this but I've > been using the current CVS code in a commercial product with > post-install scripts among a bunch of platforms with no problem so far. Pure luck. Let me reconstruct the problem. Look at generate_uninstall, it's called by main.c:411->install.c:1505. In install.c it does 1771 product = loki_openproduct(info->name); 1772 if ( ! product ) { 1773 product = loki_create_product(info->name, info->install_path, info->desc, ... 1779 info->product = product; ... 1955 loki_closeproduct(product); which in turn does free(product); so now info->product points to already freed memory! next, main.c:412 calls install_postinstall() which in turn calls run_script() which calls get_optiontags_string() at install.c:1527. And this one finally does install.c:1669 for ( comp = loki_getfirst_component(info->product) which is at setupdb.c:786: product_component_t *loki_getfirst_component(product_t *product) { return product->components; } Say hello to Mr Segfault! I suppose glibc decides to defer actually freeing info->product so it doesn't crash always. It crashed for me when I compiled loki-setup on SuSE 8.1 with glibc 2.2 and ran it on a glibc 2.3 system. You can also use valgrind, it will tell you about illegal reads on already freed memory. cu Ludwig -- (o_ Ludwig.Nussel at gmx.de //\ PGP Key ID: FF8135CE V_/_ ICQ: 52166811 From megastep at megastep.org Thu Apr 29 21:26:46 2004 From: megastep at megastep.org (Stephane Peter) Date: Thu, 29 Apr 2004 18:26:46 -0700 Subject: Memory leak fixes in setupdb and setup Message-ID: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> I just committed a bunch of fixes to memory management in both loki_setupdb and loki_setup. Basically the root of this problem is that in libxml, xmlGetProp() returns a malloced string, that needs to be explicitly deallocated. This just came to my attention recently when running valgrind on some of my projects, and I started to clean up setup as well. Unfortunately we really abuse this function all over the code. Setupdb should be mostly clean now, but loki_setup is going to be a royal pain to fix. I only fixed the most easy functions so far. On the other hand, the urge is not too strong since it's an installer and the user usually doesn't have time to notice the leaks... Anyway, if you notice any weirdness in the current CVS snapshot, please let me know. -- St?phane Peter megastep at megastep.org From icculus at clutteredmind.org Fri Apr 30 03:04:27 2004 From: icculus at clutteredmind.org (Ryan C. Gordon) Date: Fri, 30 Apr 2004 03:04:27 -0400 Subject: [lokisetup] Memory leak fixes in setupdb and setup In-Reply-To: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> References: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> Message-ID: <1083308667.1115.2.camel@localhost> > Anyway, if you notice any weirdness in the current CVS snapshot, please > let me know. Fixed a crashbug from this in copy.c; sync up to the latest CVS. --ryan. From icculus at clutteredmind.org Fri Apr 30 03:25:35 2004 From: icculus at clutteredmind.org (Ryan C. Gordon) Date: Fri, 30 Apr 2004 03:25:35 -0400 Subject: [lokisetup] Memory leak fixes in setupdb and setup In-Reply-To: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> References: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> Message-ID: <1083309935.1110.7.camel@localhost> > Anyway, if you notice any weirdness in the current CVS snapshot, please > let me know. Ugh, just hit another bug in copy.c...look for the call to add_bin_entry()...we free "symlink", but add_bin_entry stores the pointer from libxml, so you dereference free()'d memory on the "Type '%s' to start the game" message. How much memory does libxml leak in the worst case? A few bytes per XML tag/attribute? I'm inclined to suggest you back out the change and let it leak, since this is just going to cause a lot of subtle bugs. Alternately, these are the sort of things valgrind should find...funny that valgrind spurred this change in the first place. :) --ryan. From megastep at megastep.org Fri Apr 30 17:48:11 2004 From: megastep at megastep.org (Stephane Peter) Date: Fri, 30 Apr 2004 14:48:11 -0700 Subject: [lokisetup] Memory leak fixes in setupdb and setup In-Reply-To: <1083309935.1110.7.camel@localhost> References: <71FCAB31-9A45-11D8-B138-000A959DD562@megastep.org> <1083309935.1110.7.camel@localhost> Message-ID: <13174FEB-9AF0-11D8-B138-000A959DD562@megastep.org> OK, i have to admit I didn't try out the changes before committing. I just spent a couple of days doing the exact same kind of changes to a lot of code, but errors slip by... I agree this is potentially dangerous, but I'm rather inclined myself to do things right, at least fix the more obvious leaks. The leaks are actually a few bytes per tag, but unfortunately this is often code that is called often. Overall, yeah, the leaks are barely noticeable. I'm gonna have to release an installer soon for my own purposes, so I'll run this through valgrind and debug any more problem I find... On another topic, I also committed changes to detect Gentoo in setupdb. :) On Apr 30, 2004, at 12:25 AM, Ryan C. Gordon wrote: >> Anyway, if you notice any weirdness in the current CVS snapshot, >> please >> let me know. > > Ugh, just hit another bug in copy.c...look for the call to > add_bin_entry()...we free "symlink", but add_bin_entry stores the > pointer from libxml, so you dereference free()'d memory on the "Type > '%s' to start the game" message. > > How much memory does libxml leak in the worst case? A few bytes per XML > tag/attribute? I'm inclined to suggest you back out the change and let > it leak, since this is just going to cause a lot of subtle bugs. > > Alternately, these are the sort of things valgrind should find...funny > that valgrind spurred this change in the first place. :) > > --ryan. > > > -- St?phane Peter megastep at megastep.org