Rick,
I tried your last commit. I can still get the same hang.
(By the way, I coded up the thread local storage alternate solution
and it seems to work nicely. I'll post on that later.)
Here is the stack trace from the RexxDlgProc thread, on 64-bit
Windows. It's long, but go all the way to th
David:
> If you discover problems or weird behaviour please let me know.
>
just peeking and poking on Windows using pdcurses and ncurses from trunk.
Some test scripts fail, e.g.
test3-6.rex:
F:\work\svn\oorexx\incubator\orxcurses>test3-6.rex
44 *-* lf = '.window~ASCII_LF~d2c()
I don't know of any easy way to do that. This is basically a telephony
implementation of FastCGI where it's creating threads based on connections
from an Asterisk server and then the individual threads are processing the
interaction between Asterisk and the Caller for the duration of the call.
I h
Man, these stack traces don't make any sense at all. It's like the
code is randomly jumping around to different places. I suspect the
only way I'd be able to solve this is if I could recreate it here and
poke around in the debugger myself looking for clues.
Rick
On Thu, Feb 4, 2010 at 12:33 PM,
The exception stack trace looks identical to the last, which doesn't
make any more sense to me than the last time. The other threads are
very similar, so I'd still like to see stack traces for the ones
indicated below. I'm seeing a lot of things that really should not be
happening here.
On Thu,
It would IF RexxSQL was 64-bit. To my knowledge the binaries that are
out there are 32-bit and thus will not load under ooRexx 64-bit. If you
could obtain or build a 64-bit RexxSQL binary it should work fine.
David Ashley
On 02/03/2010 11:00 PM, Bill Turner, WB4ALM wrote:
Does ooRexx V4.0 (
I've still got the debugger running so I can look up anything you need.
Error:
Unhandled exception at 0x77fcb333 in rexx.exe: 0xC005: Access violation
writing location 0x.
Threads:
1436__tmainCRTStartup RexxMemory::holdObject Normal 0
1480Win32 Thread
Ok, well I learned something else... When you stop the debugger it loses all
of this information so I'm going wait until the next failure, but I will
keep the debugger running next time so I can respond to these queries.
Thanks,
David Ruggles
CCNA MCSE (NT) CNA A+
Network EngineerSafe Dat
Wow, this stack trace doesn't make any sense at all. It looks like
something has seriously whacked the C stack. I'm also a bit concerned
about what I'm seeing as the top entries for some of the other frames.
I'll mark below the ones I'm interested in seeing:
On Thu, Feb 4, 2010 at 11:19 AM, Dav
ooRexx trunk on Windows 2000 Pro, ooRexx was compiled on XP and doesn't seem
to exhibit the same errors on XP.
Error:
Unhandled exception at 0x77fcb333 in rexx.exe: 0xC005: Access violation
writing location 0x.
Call Stack:
NTDLL.DLL!77fcb333()
[Frames below may b
On Thu, Feb 4, 2010 at 5:40 AM, Rick McGuire wrote:
> There's one additional thing we might consider implementing here. The
> waiting activities queue is implemented using a linked list where the
> link fields are directly contained within the activity object. This
> causes problems if there is
On Thu, Feb 4, 2010 at 1:47 AM, Rick McGuire wrote:
> On Wed, Feb 3, 2010 at 11:32 PM, Mark Miesfeld wrote:
>> What I was thinking was: for the C++ API, add an API for AttachThread
>> that took a parameter which marked the activity for that thread to
>> avoid PeekMessage. Them from ActivityMan
There's one additional thing we might consider implementing here. The
waiting activities queue is implemented using a linked list where the
link fields are directly contained within the activity object. This
causes problems if there is a reentrant situation that can cause the
same activity to be
On Wed, Feb 3, 2010 at 11:32 PM, Mark Miesfeld wrote:
> Rick
>
> (For some reason your mail didn't show up until hours after you sent it.)
>
> I have a solution that, so far, in all my testing seems to work. I'm
> not sure how to fully implement it, or if it is feasible. It has two
> parts:
>
>
14 matches
Mail list logo
