Yup, witango log and witangoevent log are useless. Even when there
aren't crashes, there are monster holes in the log.
have created my own log with a file action. It led me to the specific
action that is the culprit, but that's it. There is nothing special
about the query, just a single argument, UID of the record.
On Nov 18, 2005, at 10:01 AM, William M Conlon wrote:
You could try using <@LOGMESSAGE> within the problematic action to
record state before and after, but it already looks like te logging
thread isn't getting finished (or maybe there is some huge BLOB
getting written to your log and the log thread itself is
crashing). So try doing your own logging with a file action.
bill
On Nov 18, 2005, at 9:23 AM, Roland Dumas wrote:
On Nov 16, 2005, at 1:23 PM, Robert Shubert wrote:
Roland,
I’ve seen crashing issues move from 5.0 ro 5.5 on Windows, so
there really are no guarantees. That doesn’t change the fact that
5.5 (especially on 10.4) seems to be a much better solution.
that said…
The first thing you need to do is isolate where in the TAF it’s
crashing (if it’s always the same). You’re best bet is to add
either a file write action, email action, or a database insert
action between each major point of the TAF. You can start with
just a few, maybe even just one in the middle. But eventually you
should (hopefully) be able to isolate it down to a particular
action.
The _function has six actions. I've isolated to the single action
that is the culprit. A relatively simple search action with a left
outer join. Microscope to the XML reveals nothing out of the
ordinary. No funny business at all.
I would first try deleting that action and recreating from scratch.
done. Visually, the XML from the 'old' and the 'new' action are
identical.
There have been some discussions about TAF corruption. Try
searching for !CST, and look back through the WT list for more info.
I've had those experiences, but nothing like that here.
If the TAF in question isn’t too complex, you might just want to
recreate it. Just don’t copy any code over, just to be safe.
it would be a chunk of work, and since the crashes are associated
with only one action in one function, I'd like to get to the cause
within that small area, rather than recreate it from scratch and
rebuild the same crash.
Make sure you send all the crash info to WT. You can ask them if
there’s any hints to the problem. If the crash info isn’t
corrupted, they can usually see if it’s a TAF, TCF, datasource,
cache, etc. issue - although I make no guarantees here.
their suggestion was look at the log. Unfortunately the witango
log doesn't capture the crash, nor anything near it. Big black
holes in the log.
Robert
From: Roland Dumas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 16, 2005 3:59 PM
To: WiTango List List
Subject: Witango-Talk: crashing witango 5 on OS X
Have had this particular crash mode for a few months and not been
able to figure it out at all. It kills the witango log, so there
is nothing there. The crash happens when one application is hit,
and occurs randomly. it might occur 1 in 100 hits. What the taf
is doing is just a few queries, nothing fancy.
the thread that crashes looks like this:
Thread 23 Crashed:
0 witangod 0x00068ef8 0x1000 + 0x67ef8
1 witangod 0x000482a8 0x1000 + 0x472a8
2 witangod 0x00069cc4 0x1000 + 0x68cc4
3 witangod 0x0006b300 0x1000 + 0x6a300
4 witangod 0x00019bdc 0x1000 + 0x18bdc
5 witangod 0x0001a1d4 0x1000 + 0x191d4
6 witangod 0x00017e0c 0x1000 + 0x16e0c
7 witangod 0x0001ac90 0x1000 + 0x19c90
8 witangod 0x0014e7d8 0x1000 + 0x14d7d8
9 libSystem.B.dylib 0x90024910 _pthread_body + 0x28
any clues where to look for this.
(pls don't say upgrade to 5.5. The client has not had enough
trouble free service from witango to be confident in another
version.)
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
