Full Tilt update for July 8 2009

[quadi]

pat, I'm so sorry, that it still does not work. Tell me, if you need more HH-files for testing.

[doc freeman]

One thing that IS NOT random is that it ALWAYS crashes while reading the last "block" of the file (I have a FileRead that reads in stream mode and I loop through reading the file in blocks at a time). And it doesn't fail on the FileRead, it fails on the subsequent call to FromUnicode with that last blob that was read.

I'm sure you on on to the real problem here. It's great that you can narrow it down to a specific call AND time. That would allow you to potentially only have to print out the unicode blob from "the last block" saving a lot of processing time and file space. I truely think seeing that "last block" from each file will narrow it down for you.

I think that narrows the field a lot. I now I'm not so sure it's a buffer issue (unless it's now the file buffer.) Remember, Full Tilt just made this change too and may have messed something but it seems if that were the case, then the same file would crash. For example, writing the EOF marker incorrectly. So I guess those types of things can be ruled out, especially if you are running PT2 without FT running on files sent to you that are closed and complete.

If I remember correctly, stream mode reads a string at a time. The other typical choice would be binary, correct? I know each language handles this somewhat differently, but Windows is Windows. Now I wonder (off the top of my head) if PB is reading the file correctly. Is an extra "last read" after the function says EOF has been reached necessary? Would it hurt or even be possible with the calls you have available? Is there a different flag necessary when opening the file? (+rb etc... does PB even use those flag types?)

You mentioned trying Windows system calls. Is this something you are allowed to do within PB? I started as a straight 'C' coding with nothing but the Windows API and Windows 2.11 many, many years ago so at one time I knew most of the system calls (then to C++, MFC and C# and .NET). Times have changed and there are many, many more funtions and its too hard to remember them all and they got much more complicated but, I certainly have resources available to look things up for you if there is anything I can do to help.

Doc

[JimmytheGeek]

I did use this function in the PokerStars notes import/export but that's only dealing with one file not all the hand history files so it's being called a lot more than what the notes import/export does.

Pat,

FWIW, I occasionally get access violations when doing an advanced notes export. I export notes every day and get an error a couple times a month. It always occurs right at the start. It's a minor annoyance, and knowing how hard this kind of thing is to track down, I've never bothered to report it.

Perhaps this is further evidence that this function is the cause of the problem!

[ptrack pat]

I did use this function in the PokerStars notes import/export but that's only dealing with one file not all the hand history files so it's being called a lot more than what the notes import/export does.

Pat,

FWIW, I occasionally get access violations when doing an advanced notes export. I export notes every day and get an error a couple times a month. It always occurs right at the start. It's a minor annoyance, and knowing how hard this kind of thing is to track down, I've never bothered to report it.

Perhaps this is further evidence that this function is the cause of the problem!

Thanks for letting me know this. It does indeed seem to point to an issue with the function.

[AAA Donnie]

I got an acces error after downloading the patch, and forcing import. It then shuts down PT2 completely. Any idea when a working patch will be available?

[ptrack pat]

I got an acces error after downloading the patch, and forcing import. It then shuts down PT2 completely. Any idea when a working patch will be available?

I don't have an idea yet because I'm coming to the conclusion that this is a software glitch in the software I used to write PT2. So I'm trying to come up with workarounds. Use this workaround until I can come up with something in PT...
viewtopic.php?f=28&t=21074

[drgfire]

Hey Pat, doc freeman, since you're talking about coding issues I'm going to add my 2 cents.

I don't know what Powerbuilder 7.x is at all (what is it?) but I'm pretty sure FromUnicode() is no WINAPI aka system call (it's not on msdn.com). Pat, where's this function from? I suspect you could do it with pure WINAPI if that's possible in your development environment. google search turned something up, but I haven't tried it out since .net provided easier methods for ft_hh. I guess I could provide you some C function however, if that would help. Give me the needed signature (input/output with description) of such a function and I'm going to have a look at what I can do.

Anyway, if I recall correctly from the thread, somewhere you stated that the import fails unreproducibly in release build, but not in debug builds. From my experience this has *always* something to do with some sort of "buffer overflow", but don't take the phrase too literally.

The basic thing is, unicode characters take up 2 bytes, whereas ascii chars are 1 byte. It might be possible that this in not taken into account somewhere in the code, or probably some helper function or whatever isn't laid out for that.

Back to "buffer overflow" (I don't like the term). There is much more to it than simply accessing arrays out-of-bounds. In C/C++
you can do everything to wreak havoc, there doesn't have to be arrays involved. It would help if I'd know what language PT is developed in, as the buffer overflow stuff I'm talking about is C/C++ related, but the point is:

In debug mode, compilers tend to induce lots of padding into all sorts of constructs (structs, arrays, ...) no matter if they're dynamically allocated or not (the stack too might be laid out completely differently). Therefore, buffer overflows might be harmless (not overwriting critical memory regions, or not out-of-true-bounds at all).
In release mode, the compiler doesn't perfrom this kind of excessive padding, so the overflow becomes apparent.
What makes this kind of error so nasty is that it's inherently impossible to "debug", only stack traces from release builds might provide some clue, albeit they likely won't show the true reason.

Well, I don't know if this helps. Is it possible to obtain stack traces on Windows? Could be worth a try. Another approach would be to inspect the whole code path very carefully (from start to finish), in order to find places where things could go wrong. This is very tedious...

[doc freeman]

drgfire,

What you say is very true. I've seen exactly the same as you in debug versus release and the fact that this seems semi random points to the same thing. I've also just mentioned the exact problem with the difference in "chars" and "bytes" when working with Unicode to Pat in a PM.

FromUnicode is a PowerBuilder (it was kinda like a cross between VB and dBase if I remember correctly) funtion, not win API. Since neither of us know PB, well, the best we can do is offer Pat ideas and possible win API calls to fix it but we don't know how certain functions handle stacks, local and global vars etc... in PB. I've been doing so in PMs lately so this thread doesn't turn into a circus.

The extreme is creating a DLL for him as we have been discussing but that presents possible challenges that we are not aware of like how does PB handle outside API calls, threading issues etc. Also, source code and his ability to read and compile the DLL would be necessary to ensure the integrity of PT.

Maybe the three of us can trade emails so we can take this off line and not duplicate Pats effort?

Doc

[ptrack pat]

drgfire, PowerBuilder is a software program similar to VB, it has it's own language so that is where FromUncode comes from. I'm not sure what that function is doing behind the scenes but it's supposed to take a Unicode blob and convert it to an ANSI string. I had looked into trying to call a Windows API WideCharToMultiByte from within my code but that wasn't working...at least it wasn't returning me any readable text like I hoped.

[jdiferdi]

[quote="ptrack pat"]Close FullTilt and PT2.
Open PT2 and the Full-Tilt auto-import window.
Click the View Log link. quote]

Where is the "View Log Link" I don't see a ling on the Full Tilt auto-import window?