Another patch glitch

[OddOne]

No go on the latest patch. Crashes out due to an apparent bug in launcher_startup.

Error log:

Unhandled exception in thread started by <function launcher_startup at 0x01ACC830>
Traceback (most recent call last):
File "outspark.py", line 754, in launcher_startup
File "outspark.py", line 188, in update_app
File "outspark.py", line 484, in download
File "outspark.py", line 490, in do_download
File "urlgrabber\grabber.pyc", line 893, in urlgrab
File "urlgrabber\grabber.pyc", line 658, in parse
File "ntpath.pyc", line 500, in abspath
TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str


Environment: Windows XP Pro SP2, up-to-date with regard to patches and updates.

It worked up until I fired it up this morning and it grabbed the latest patch.



Request: Put in some sort of alternative means to launch the game without having to use the launcher only, for users that have some computer expertise. Self-updating launchers are great unless/until they don't work. Then they're just annoying. Hard to get people to spend money in your game store if they can't play the game.



Another request: Let the user know there's a problem immediately instead of simply idling the launcher and popping up an "oops, there was a problem" dialog after the user closes the launcher. That's just retarded.

oO

[lanceyuen]

how do u deal with this matter??

[OddOne]

how do u deal with this matter??

Are you having the same problem?

If I had access to the outspark.py file's source code I'd put in some debug code to see what's being fed to the API call, and then fix the calling routine's problem.

But as a mere player and not one of the developers I don't have access to that, so I get to wait for the patch to be patched. The big question is whether the error happens before or after the patch checker - if it's before, Outspark will have to make a manual download available to fix the problem.

oO

[lanceyuen]

Are you having the same problem?

If I had access to the outspark.py file's source code I'd put in some debug code to see what's being fed to the API call, and then fix the calling routine's problem.

But as a mere player and not one of the developers I don't have access to that, so I get to wait for the patch to be patched. The big question is whether the error happens before or after the patch checker - if it's before, Outspark will have to make a manual download available to fix the problem.

oO

emm.. i think its merely same or actually same.
****. now: error connecting to update server:(11001,'getaddrinfo failed')

[lanceyuen]

AttributeError: 'NoneType' object has no attribute 'split'
Unhandled exception in thread started by <function launcher_startup at 0x0222A8F0>
Traceback (most recent call last):
File "outspark.py", line 603, in launcher_startup
File "outspark.py", line 173, in update_app
File "outspark.py", line 344, in delete
File "outspark.py", line 785, in sh_delete
File "shutil.pyc", line 161, in rmtree
File "shutil.pyc", line 159, in rmtree
WindowsError: [Error 3] The system cannot find the path specified: 'C:/DOCUME~1/OMEGAG~1/LOCALS~1/Temp/Fiesta.Patch.64-65b.7z/*.*'


.... now its like this.

[OddOne]

This is both good and bad news.

It's bad in that the launcher's jacked by bugs in the latest patch.

However, it's good in that we're seeing changes to the problem, which means that someone's working on it right now.

Let's just hope they find and fix it quickly and easily. :D

oO

[lanceyuen]

haha. ok then. i shall wait. quite boring now.. no games after all.. but.. i hope they will fix this problem as soon as possible! :D

[Xanthros]

Are you having the same problem?

If I had access to the outspark.py file's source code I'd put in some debug code to see what's being fed to the API call, and then fix the calling routine's problem.

But as a mere player and not one of the developers I don't have access to that, so I get to wait for the patch to be patched. The big question is whether the error happens before or after the patch checker - if it's before, Outspark will have to make a manual download available to fix the problem.

oO

Watch it in memory with SoftIce or something else that's at the kernel debugger level so you can see it before it bails (pick your poison, many choices - I prefer to see it in an ASM)

Edit: Edited my post to add a bit more info, and my thoughts

X-

[OddOne]

Watch it in memory with SoftIce ;)

I could do that, actually, but they probably couldn't afford what I'd have to charge to justify playing trace-the-stack for someone else's code. :D

Besides, aren't they suposed to have at least done a few test runs before pushing patches out to the public?



Truth be known there's probably a typo in "File "ntpath.pyc", line 500, in abspath". Someone probably inadvertantly passed a constant to it as a buffer pointer, which would explain the error messsage ("TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str"). API calls don't tend to like that very much.

oO

[OddOne]

Oh, one more thing...

If I find out (eventually?) that all my game-store-bought stuff lost a day or more during the game's downtime thanks to that patch breaking everything, Outspark can count on not getting a cent from me ever again. I'd strongly advise that Outspark credit the downtime to players that purchased content from the game store.

oO

[Xanthros]

I could do that, actually, but they probably couldn't afford what I'd have to charge to justify playing trace-the-stack for someone else's code. :D

Besides, aren't they suposed to have at least done a few test runs before pushing patches out to the public?



Truth be known there's probably a typo in "File "ntpath.pyc", line 500, in abspath". Someone probably inadvertantly passed a constant to it as a buffer pointer, which would explain the error messsage ("TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str"). API calls don't tend to like that very much.

oO

I have SoftIce as part of my toolkit, with many other goodies - profession is infosec and vuln-dev, so it's something I see daily. As for test runs, my thoughts are that the dev machines in question are stock installs with as many video tests as possible. I'd like to see them start a thread with every 'successful' install/upgrade/patching being posted so they know what works, and what doesn't. Process of elimination goes a very long way in troubleshooting as well. That said, their latest patch is being misplaced on a few system configurations for a reason that I can't begin to guess at.

There's a few issues in the patcher I found, with overflows while attempting to read some of the registry keys. I am trying to get this damn thing to run in WINE (which is proving to be interesting). If they had a linux version, I'd gladly play it while running it through Valgrind so I could just give them a full dump.

The scary part about the concept of 'abspath' hints at an absolute path, and overseas versions of Windows do not always behave the same, due to the crypto that is not allowed in a few specific countries. I doubt they're using anything that's only meant to be run on 128 bit crypto-capable machines, but I try to assume nothing.

X-

[bship810]

I'm having a problem with the new patch also. Prior to the patch it was working fine. This what it says:

Errors Occured
See the Logfile 'C:\Program Files\Outspark\Launcher\outspark.exe.log' for details

when i go there, this is what it says:
Traceback (most recent call last):
File "outspark.py", line 6, in <module>
ImportError: No module named OskRest

Hopefully this gets fixed

[OddOne]

I have SoftIce as part of my toolkit, with many other goodies - profession is infosec and vuln-dev, so it's something I see daily. As for test runs, my thoughts are that the dev machines in question are stock installs with as many video tests as possible. I'd like to see them start a thread with every 'successful' install/upgrade/patching being posted so they know what works, and what doesn't. Process of elimination goes a very long way in troubleshooting as well. That said, their latest patch is being misplaced on a few system configurations for a reason that I can't begin to guess at.

Nice - I'm a security software developer myself. Specialty is secure data destruction. (Subspecialty is crypto, which might have something to do with why my software has been publicly available for years but the last four years' worth of releases are uncracked to this day. Nothing says "I wub joo" to a cracker like self-modifying program code, relocatable code, and cryptographically strong PRNGs.)



There's a few issues in the patcher I found, with overflows while attempting to read some of the registry keys. I am trying to get this damn thing to run in WINE (which is proving to be interesting). If they had a linux version, I'd gladly play it while running it through Valgrind so I could just give them a full dump.

Yeah, I noticed a few memory leaks here and there from this game, pretty much from the first version I've played.



The scary part about the concept of 'abspath' hints at an absolute path, and overseas versions of Windows do not always behave the same, due to the crypto that is not allowed in a few specific countries. I doubt they're using anything that's only meant to be run on 128 bit crypto-capable machines, but I try to assume nothing.

I don't think crypto is really much of a concern for the game unless it's using the crypto DLLs for authentication or data traffic protection. That said, not everyone has Windows installed in C:\WINDOWS. My dev machine runs 26 partitions and has a WINDOWS directory (and a standalone install of some version or another of Windows) in fourteen of them, so if it's hardcoded for Win in any specific location on my box it'll puke.

There's no reason to hardcode a Win directory anyway - there's a friggin' API call specifically to return the Windows install directory (and another one for Win/System) so that should never be hardcoded anyway.

oO

[OddOne]

My brother just logged in successfully. I tried and got this in the error log:

Unhandled exception in thread started by <function launcher_startup at 0x01A1D870>
Traceback (most recent call last):
File "outspark.py", line 754, in launcher_startup
File "outspark.py", line 187, in update_app
File "outspark.py", line 484, in download
File "outspark.py", line 490, in do_download
File "urlgrabber\grabber.pyc", line 893, in urlgrab
File "urlgrabber\grabber.pyc", line 658, in parse
File "ntpath.pyc", line 500, in abspath
TypeError: _getfullpathname() argument 1 must be (buffer overflow), not str


His WinXP install's in C:\WINDOWS. Mine's in M:\WINDOWS.

oO

[bship810]

I love how the GM's get back to us so fast... :(

[OddOne]

I love how the GM's get back to us so fast... :(

Well I bet they're having a load of fun dealing with the fact that the last update broke the game for just about everyone, and the fix left the game broke for a large chunk of the userbase.

I imagine it's chaos at Outspark right now. So reasonable patience is called for methinks.


However, the key word is "reasonable." The longer I see myself unable to get into the game the less value it holds for me, and conversely the less likely I am to spend money on it. Given that this went down the day after I bought a bunch of SparkCash my patience is definitely finite.

oO