Missing line numbers in bug report

delphi package - automated exception handling

Missing line numbers in bug report

Postby Tahtu » Thu Dec 08, 2016 8:00 pm

I don't have line numbers inside my bug report, if I compile:
dcc32.exe /B -GD -$D- "Project1.dpr"
Now I have a file size of 23,257 KB.

Inside the Project1.map file, I have only line numbers for this files: madTypes,madStrings,madStrings,madTools,madTools,madZip and madCrypt.

After running madExceptPatch.exe, I have a file size of 23,561 KB.

... and if I create a bug report, the line numbers are missing.


I need to compile with this to get the line numbers:
dcc32.exe /B -GD -$D+ "Project1.dpr"
Now, I have a file the same file size of 23,257 KB.

Inside the Project1.map file now the line numbers are given for all units.

After running madExceptPatch.exe, I have a file size of 23,730 KB.

My ready compiled setup program has a download size of 5,012 KB.


If I compile my application with EurekaLog6, it gets a file size of 23,061 KB.

The ready compiled setup program a download size of 4,675 KB.


Why do I have to use "-$D+" for creating a .map file with line numbers? I'm using Delphi XE2, Update 4, Hotpack 1.


With madExcept I have a file size of 700 KB more than with EurekaLog6. After using the high compressing setup creation program (InnoSetup), madExcept has 350 KB more download size. I don't think, this difference is given of different compression only...

PS:
Delphi XE2 has routines for ZIP and ZLIB enclosed. If you would use them instead of your own routines, this would decrease my file size, sinde I still use that routines of Delphi too. But this would be less than 100 KB I think. So it's not really important - only for your note.
Last edited by Tahtu on Wed Dec 14, 2016 9:32 am, edited 1 time in total.
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm

Re: Missing line numbers in bug report

Postby madshi » Thu Dec 08, 2016 9:10 pm

I think $D is "debug information" in the compiler settings? In order for the map file to be "complete", the compiler "debug information" option needs to be turned on. That's just the way it is.

The size difference probably comes from a different compression algorithm. I'm compressing, then encrypting. Due to the encryption, InnoSetup can't squeeze out any more size. If I used a stronger encryption, the file size would go down. However, it comes with its own problems:

1) Older Delphi versions don't have zlib included.
2) Stronger compression also means longer time to uncompress during runtime, which means slower startup of the EXE. Haven't benchmarked this, though, might be negligable, I don't know.

I'll add this on my list of things to look at. But it's a change I most probably will not implement before v5.0.
madshi
Site Admin
 
Posts: 9477
Joined: Sun Mar 21, 2004 5:25 pm

Re: Missing line numbers in bug report

Postby Tahtu » Fri Dec 09, 2016 6:09 am

madshi wrote:I think $D is "debug information" in the compiler settings? In order for the map file to be "complete", the compiler "debug information" option needs to be turned on.

Ok. I didn't found this hint inside your documentation.

Maybe madExceptPatch.exe can give a hin, if I didn't us $D+...

madshi wrote:The size difference probably comes from a different compression algorithm.

I got a further idea: EurekaLog6 works with AnsiStrings - not with Unicode. So the strings of the .map file will be stored with 1 byte per character. I don't know, how madExcept stores the strings. If you store it as Unicode, you takes two bytes per character. Since the most methods are written in native ASCII characters, maybe you could reduce the needed space by converting the strings to UTF-8 before compressing it. But I don't know the compression algorithm, if they is able to handle this as well without converting it to UTF-8. It was just an idea of my...

madshi wrote:I'm compressing, then encrypting. Due to the encryption, InnoSetup can't squeeze out any more size.

If I compile my program without madExcept and without EurekaLog, it has a file size of 22,785 KB. The ready compressed download size is 4,387 KB. So madExcept leave a footprint of 803 KB inside my program. But in the ready compressed setup program, the footprint has a size of 625 KB. So InnoSetup is able to compress your compressed footprint further more.

madshi wrote:1) Older Delphi versions don't have zlib included.

I'm sure, you would be able to handle different ways for different Delphi versions, if you want.
madshi wrote:2) Stronger compression also means longer time to uncompress during runtime, which means slower startup of the EXE.

I don't know how and where madExcept stores the data inside the .exe file. But it would be possible to store is a resource. I think, this is the prefered way to storing data in .exe files.
The .map file informations are not needed to execute my .exe file. They will be needed only if an exception was detected by madExcept.

So the decompressing of the map file data could be handled while the first expression occurs. I think you create the stack trace in a separated thread to show the exception dialog immediately. And inside the exception handler, I can't access to the stack trace, if I don't synchronize it with GetBugReport. So you could decompress the .map file data inside that separated thead at that time. On this way, you don't waste CPU resources of decompressing the .map file data on every program start.

madshi wrote:Haven't benchmarked this, though, might be negligable, I don't know.

I left the information about the file sizes and my ideas here, to assist you. How do you handle that information is up to you.

Human who wants to change something are finding ways to change something. Humans who don't want to change something are finding arguments not to change it. It's up to you, what you are looking for. Imho it wasting time to looking for arguments not to change something... :wink:
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm

Re: Missing line numbers in bug report

Postby madshi » Fri Dec 09, 2016 9:57 am

Tahtu wrote:Maybe madExceptPatch.exe can give a hin, if I didn't us $D+...

madExceptPatch doesn't know which dcc32 parameters were used.

Tahtu wrote:I got a further idea: EurekaLog6 works with AnsiStrings - not with Unicode. So the strings of the .map file will be stored with 1 byte per character. I don't know, how madExcept stores the strings. If you store it as Unicode, you takes two bytes per character.

The map file information is stored as ansi strings.

Tahtu wrote:If I compile my program without madExcept and without EurekaLog, it has a file size of 22,785 KB. The ready compressed download size is 4,387 KB. So madExcept leave a footprint of 803 KB inside my program. But in the ready compressed setup program, the footprint has a size of 625 KB. So InnoSetup is able to compress your compressed footprint further more.

InnoSetup is able to compress the madExcept added *code*, but the map file information is encrypted, and encrypted data can't be compressed any further.
madshi
Site Admin
 
Posts: 9477
Joined: Sun Mar 21, 2004 5:25 pm

Re: Missing line numbers in bug report

Postby Tahtu » Wed Dec 14, 2016 9:39 am

Tahtu wrote:After running madExceptPatch.exe, I have a file size of 23,730 KB.

My ready compiled setup program has a download size of 5,012 KB.


If I compile my application with EurekaLog6, it gets a file size of 23,061 KB.

The ready compiled setup program a download size of 4,675 KB.

Now I tested EurekaLog 7.5. The filesize and download size of it is nearly the same like the actual madExcept sizes.

EurkaLog has a lot of bugs more than madExcept and the developer of EurekaLog are much more ignorant than you. But EurekaLog 7.5 has also be more detailed call stack information.

Now I updated from EurekaLog 6 to EurekaLog 7.5. Not a good solution, but I can't find a good solution for creating call stacks at all.
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm

Re: Missing line numbers in bug report

Postby madshi » Wed Dec 14, 2016 9:41 am

In which way is the EurekaLog callstack more detailed?
madshi
Site Admin
 
Posts: 9477
Joined: Sun Mar 21, 2004 5:25 pm

Re: Missing line numbers in bug report

Postby Tahtu » Wed Dec 14, 2016 9:47 am

madshi wrote:In which way is the EurekaLog callstack more detailed?

If you want to get my assistance to improve madExcept, first of all we have to work on you kind of thinking. Serving an other is the way, you still didn't understand.

Also you often are looking for reasons not to change something instead of searching for ways to change it. On this base, I can't serve you - it's wasting energie talking with people like you.

Have a nice live!
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm

Re: Missing line numbers in bug report

Postby Tahtu » Sun Jan 01, 2017 7:31 am

madshi wrote:In which way is the EurekaLog callstack more detailed?

Togehter with the update to EurekaLog 7.5, I updated Delphi from XE2 to XE4.

Today, I believe the more detailed information inside the callstack based on the Delphi update - not on differences between madExcept and EurekaLog. But I didn't validated this...
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm

Re: Missing line numbers in bug report

Postby madshi » Sun Jan 01, 2017 9:50 am

I suppose it's possibly but I can't say for sure. FWIW, madExcept has a very complex "noise filter" to remove callstack items which madExcept believes are not really part of the callstack. The noise filter involves disassembling all the functions that are potentially part of the callstack in order to find out if they could possibly call each other etc. Usually the noise filter works very well, cleaning the final reported callstacks up very nicely. But there are probably a few rare cases where the noise filter may accidently remove some true items. In that case EurekaLog may produce a "better" callstack. But usually, last time I tested (which is a long time ago), EurekaLog callstacks have a lot more noise in it.

So it's possible that when you see EurekaLog produce a more detailed looking callstack, either madExcept filtered out too many items. Or the added detail could be incorrect callstack items which EurekaLog didn't manage to filter out. Or, as you say, a different Delphi version could also produce different results.

Things will also depend on the bitdepth (stack tracing is totally different in x64 compared to x86), and on compiler settings (e.g. forced stack frames or not).
madshi
Site Admin
 
Posts: 9477
Joined: Sun Mar 21, 2004 5:25 pm

Re: Missing line numbers in bug report

Postby Tahtu » Sun Jan 01, 2017 10:16 am

Like you understood: madExcept is still interessted for me, since also EurekaLog is still far away from perfect.

But without a serious looking exception dialog, I will not try madExcept further more...
Tahtu
 
Posts: 51
Joined: Thu Sep 06, 2012 12:03 pm


Return to madExcept

Who is online

Users browsing this forum: Google [Bot] and 3 guests

cron