[Fixed] PortableApps.com Installer Freezes

19 posts / 0 new

Last post

June 20, 2010 - 6:04pm

Pyromaniac

Offline

Last seen: 7 years 9 months ago

Joined: 2008-09-30 19:18

[Fixed] PortableApps.com Installer Freezes

This isn't the first time I noticed it, but I was able to fix this problem before.
Look at this image.

The installer freezes up like that sometimes and it doesn't ever pick up again. It just stays like that. Normally, when that happens, I kill the process makensis.exe and exit out of everything thats open and recompile again. That usually works. with 2.0.2 though, its not working. I noticed that mainly happens with larger apps.

Now, if you look at the task manager, you'll see that makensis.exe is using 0% CPU. It jumps around a lot, going as high up as 94% and then making huge increases and decreases every second. I waited for about 25 minutes the last time I tried to compile (from the time it gets to that point) and then I just figured I'd show it to you.

I don't want no bugs in my pai

(thanks)

June 20, 2010 - 7:57pm

John T. Haller

Offline

Last seen: 1 hour 9 min ago

Joined: 2005-11-28 22:21

Zip It Up

I'll need your exact files to reproduce it so please zip them up and place them somewhere online so I can check them out. I've never seen it before.

Sometimes, the impossible can become possible, if you're awesome!

June 21, 2010 - 1:14pm

(Reply to #2) #3

Pyromaniac

Offline

Last seen: 7 years 9 months ago

Joined: 2008-09-30 19:18

well I tried to compile again

after a good night's rest for me and my PC and this time, it only took 2 minutes after the "stopping point" before it finished compiling.

that's clever how you set up the loading bar to go, though.

June 21, 2010 - 1:25pm

(Reply to #3) #4

John T. Haller

Offline

Last seen: 1 hour 9 min ago

Joined: 2005-11-28 22:21

Time

Yeah, it's gonna take a bit longer on your older PC to compile. An Intel Celeron lacks some of the extra things that apps like compilers and imaging/video apps use to speed processing. We have NSIS set for LZMA compression with the SOLID switch on, which produces the smallest possible EXE but takes the most processing power of any of the options. The reason is that, as a developer, we only have to suffer through it once. But everyone else has to deal with the bandwidth of downloading it. So a little pain for one of us saves a little pain for a lot of others.

Sometimes, the impossible can become possible, if you're awesome!

June 21, 2010 - 1:28pm

(Reply to #4) #5

Pyromaniac

Offline

Last seen: 7 years 9 months ago

Joined: 2008-09-30 19:18

good point

I can only imagine what it would be like trying to compile something big like OO.o on this computer!

June 28, 2010 - 11:40pm

(Reply to #5) #6

OliverK

Offline

Last seen: 1 year 7 months ago

Joined: 2007-03-27 15:21

Its the RAM that eats it. I

Its the RAM that eats it. I couldn't compile Geany Portable with this computer, and it had the same amount of RAM as yours.

Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world

June 30, 2010 - 1:10pm

(Reply to #6) #7

gluxon

Offline

Last seen: 2 years 4 months ago

Joined: 2008-06-21 19:26

Well imagine it All the

Well imagine it

All the Eclipse editions must add up to at least 1.5 Gig.

June 21, 2010 - 1:40am

Soulmech

Offline

Last seen: 10 years 7 months ago

Joined: 2010-03-03 10:52

Is there any disk activity

Is there any disk activity during these CPU spikes? Task Manager can show the numbers of reads and writes under Processes if you change which columns to view.

SWAG

June 21, 2010 - 1:17pm

(Reply to #8) #9

Pyromaniac

Offline

Last seen: 7 years 9 months ago

Joined: 2008-09-30 19:18

I think its Windows Update

every few weeks or so, I turn it on to update, and whenever its on, performance declines, little by little and then it just suddenly freezes up.

So I turned it off before compiling again.

And for the CPU spikes, that happens only with makensis.exe, all the other processes remain at 00 or 01 most of the time (Windows Update spikes every now and then too).

June 28, 2010 - 2:08pm

#10

computerfreaker

Offline

Last seen: 11 years 4 months ago

Joined: 2009-08-11 11:24

I was easily able to

I was easily able to reproduce this on my parents' old PC.
On my usual development machine (2 CPUs, 3 GB of RAM) building the Iron Portable installer usually takes around 2-3 minutes. On my parents' old PC (1 CPU, 1 GB of physical RAM but a 2 GB pagefile), I couldn't get the Iron Portable installer to build at all. It kept hanging around 85%, just like in your screenshot. I let it run for close to half an hour, but it didn't make any progress at all once it started hanging.
To prove that the Iron Portable files weren't to blame, I borrowed my sister's machine (specs equal to my dev machine - 2 CPUs, 3 GB of RAM) and the Iron Portable installer built as usual.

It looks like NSIS is trying to only use physical RAM - during the build process on my parents' computer, it was using all but 3 MB or so of physical RAM and apparently ignoring the pagefile. What the heck?? (Should I be reporting this to the NSIS devs?)

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

June 28, 2010 - 6:41pm

(Reply to #10) #11

Chris Morgan

Offline

Last seen: 7 years 7 months ago

Joined: 2007-04-15 21:08

Should still finish

I remember compiling a big LZMA\Ultra installer a year or more ago, I think it may have been an Inkscape installer, which would mean compressing a couple of hundred megabytes down to forty or so, which I was running on an XP (AMD Athlon XP 2000+) machine with 368MB of RAM. While on a 2000 machine with 2GB of RAM (Intel E6300, so a fair bit faster too) it took a few minutes to do it, on the XP machine it took, if I recall correctly, over six hours. But it did finish.

It's quite possible that it's not NSIS trying to only use physical memory, but rather than it goes changing the contents of the memory about so much that it can't swap it to disk - it's being used too much. There was a recent message in the NSIS changelog (for changes since 2.46) about increasing memory efficiency, but I doubt it would affect you here. Quite simply, if you're working with building installers and are using LZMA\Ultra compression, you need 400MB of RAM free. Or you need to not mind about the computer being busy and unusable for anything else overnight.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

June 29, 2010 - 12:04am

(Reply to #11) #12

computerfreaker

Offline

Last seen: 11 years 4 months ago

Joined: 2009-08-11 11:24

OK, I guess it's the machine then.

I gave it around 20-30 minutes; I didn't anticipate it needing 6 hours. Not beautiful, but I reckon I can live with that.
This machine's 4 years old, too, so it's a pretty slow behemoth. I'm not too surprised.

Chris MorganIt's quite possible that it's not NSIS trying to only use physical memory, but rather than it goes changing the contents of the memory about so much that it can't swap it to disk - it's being used too much.

That's a reasonable explanation. I watched makensis.exe in the Task Manager and its RAM usage kept jumping around; it was definitely doing something in there.

Well, I'll just let it run overnight then, or maybe I'll borrow my sister's machine again.

Thanks, Chris!

computerfreaker

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

June 29, 2010 - 12:44am

#13

Soulmech

Offline

Last seen: 10 years 7 months ago

Joined: 2010-03-03 10:52

Maybe consider using less

Maybe consider using less compression so that people with slower/older computers are able to install apps?

SWAG

June 29, 2010 - 12:55am

(Reply to #13) #14

Chris Morgan

Offline

Last seen: 7 years 7 months ago

Joined: 2007-04-15 21:08

Not the problem

This is about generating the app installers. The installers in extraction don't use anywhere near as much memory - something like 32MB compared to the 640MB of compressing.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

June 29, 2010 - 12:06pm

#15

John T. Haller

Offline

Last seen: 1 hour 9 min ago

Joined: 2005-11-28 22:21

Possible Work-Around

As mentioned, this is about the compression used when compiling an installer. Unless you have enough RAM, it will have to swap out A LOT to the hard drive and take an unacceptably long time. The reason we use such high compression is to make the installer as small as possible so that users can download as fast as possible. Installing (uncompressing) doesn't take much RAM at all.

I'm thinking that I could perhaps add the ability for the generator to detect that we're running on a low-RAM PC (under 2GB) and switch to using a lesser compression just for that installer. It'd show up as an option on the page where you select the app and select whether to enable the interactive prompts. I'd have it short-circuit the ability to pass in the path and automatically start. The checkbox would be unchecked automatically for PCs with enough RAM and checked automaticaly for PCs without enough RAM.

Thoughts?

Sometimes, the impossible can become possible, if you're awesome!

June 29, 2010 - 12:30pm

(Reply to #15) #16

Simeon

Offline

Last seen: 8 years 3 months ago

Joined: 2006-09-25 15:15

sounds good

if its not too much work for you.
I think most people wont need it (might be wrong though).

"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate

June 29, 2010 - 12:40pm

(Reply to #16) #17

Pyromaniac

Offline

Last seen: 7 years 9 months ago

Joined: 2008-09-30 19:18

sounds good to me

I'm not sure though, how much faster this could make the compiling process go though?

June 29, 2010 - 1:08pm

(Reply to #17) #18

John T. Haller

Offline

Last seen: 1 hour 9 min ago

Joined: 2005-11-28 22:21

A Ton

The other compression methods use *MUCH* smaller page sets in RAM. The fact that you don't have enough RAM is the whole reason the installer takes so long. So the installer will take normal time (for your CPU of course) rather than 6 hours if you notch it down from LZMA /solid.

Try it yourself. Edit the file PortableApps.comInstaller\App\installer\PortableApps.comInstaller.nsi. Change line 70 from SetCompressor /SOLID lzma to SetCompressor lzma and see how it works. Change line 80 from SetCompressorDictSize 32 to SetCompressorDictSize 8 and see how it works.

Sometimes, the impossible can become possible, if you're awesome!

June 29, 2010 - 1:34pm

(Reply to #18) #19

computerfreaker

Offline

Last seen: 11 years 4 months ago

Joined: 2009-08-11 11:24

Sounds great!

As long as it won't be too difficult for you to do, I'd really appreciate that. I do feel a bit guilty about making bigger installers, but there's not really a lot that can be done about it.

"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."

Please Help Support Us

Please consider making a donation so we can keep bringing you great software.

You are here

[Fixed] PortableApps.com Installer Freezes

Please Help Support Us

Translate Page

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com

You are here

[Fixed] PortableApps.com Installer Freezes

Please Help Support Us

Translate Page

User login

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com