|
<< Click to Display Table of Contents >> Navigation: Telegram > 2019 > 08 > 20 > Telegram_2019-08-20T05 |
2019-08-20T05:00:59
I know. I know. I just need a small help. I have again the crash (in debug session, too) and this is the stack:
2019-08-20T05:02:00
This happen sometimes (yes, again, I know...) and ONLY when I do a \deep\ refresh in browser (clear the cache)
2019-08-20T05:09:40
have you included the JclDebug as I suggested? I don't see any useful debug information
2019-08-20T05:10:15
Yes. By default. No infos from jcl
2019-08-20T05:11:01
The IW server is HSYS and compiled in 64 bit. But the problem is the same also in 32bit
2019-08-20T05:12:18
if you can recreate it in 32 bit, I suggest you to debug in 32 bits. Delphi debugger behaves better. How's your compiler and linker options (of the project)?
2019-08-20T05:12:32
I suspect that no debug info is being included. I don't see anything there
2019-08-20T05:13:11
I'll debug in 32. I have all debug infos activated
2019-08-20T05:13:33
so do you have the exception report saved by IW?
2019-08-20T05:13:43
it should contain the stack trace (full)
2019-08-20T05:14:01
No, no log is saved during the crash
2019-08-20T05:14:28
how is that?
2019-08-20T05:14:40
can you repeat in debugging?
2019-08-20T05:15:20
I don't see how it would not save the file....
2019-08-20T05:15:38
The last error is always this:
2019-08-20T05:16:58
The last error before the crash
2019-08-20T05:17:50
Yes, the last file is the one you still sayd to me that it was
ormal beahvior\
2019-08-20T05:18:22
I already explained how this happens and that it is not responsible for a crash. This is a handled exception. This is not an error. Just an exception
2019-08-20T05:18:52
Indeed. But this is always the last error log before the crash
2019-08-20T05:19:01
what crash is this? Does the application terminates?
2019-08-20T05:19:09
can you repeat in debug?
2019-08-20T05:19:10
yes
2019-08-20T05:19:31
I'll try in 32 bit with more luck
2019-08-20T05:19:36
so you install it as a service and the application just dies?
2019-08-20T05:19:46
yes
2019-08-20T05:19:59
But also in DS mode
2019-08-20T05:20:06
what is DS mode?
2019-08-20T05:20:23
sorry. not service, executable
2019-08-20T05:20:49
and what happens with your IDE? If you are debugging and the application dies, how the IDE handles it?
2019-08-20T05:21:20
Thi is the result
2019-08-20T05:21:53
and where is the call stack?
2019-08-20T05:22:11
Something is not right in your applicaiton/IDE/something else
2019-08-20T05:22:35
If there is an exception while debugging the IDE *MUST* break where the exception occurs.
2019-08-20T05:22:53
I've never seen a case where it doesn't happen, unless you don't have any debug information included
2019-08-20T05:23:34
Yes. But probably the 64bit debugger has some problems
2019-08-20T05:23:36
Have you tried to run it as INdy server and see if the same happens?
2019-08-20T05:23:58
As I told you: DEPLOY as 64 bits, but *find errors in 32 bits*
2019-08-20T05:23:59
This is another test I have to do
2019-08-20T05:24:12
Yes right
2019-08-20T05:24:52
So, I suggest you to try this:
- Build it as 32 bits, including the full debug information (the link I gave you contain the information you need)
- Get the stack trace of the error
2019-08-20T05:25:23
- Then switch to 32 bits INdy and try it too. See if the problem still happens
2019-08-20T05:26:03
Don't debug in 64 bits, unless the problem only occurs in 64 bits. 32 bits is easier to debug and the debugger is much more stable
2019-08-20T05:29:04
all right man. Sorry for wasting your time (I'll continue do it, but I can invite you in Venice to apologize... ??)
2019-08-20T05:47:56
you're welcome. it is no waste of time????
2019-08-20T05:48:17
But we can have a beer in Venice, why not? ??
2019-08-20T05:48:30
(I'm not a wine guy, sorry!)
2019-08-20T05:58:37
Don't worry. I drink everything... And I can change every mind... ??