views:

155

answers:

4

Hello all. I have a source file in my project, which has more than 65,536 code lines (112,444 to be exact). I'm using an "sqlite amalgamation", which comes in a single huge source file.

I'm using MSVC 2005. The problems arrives during debugging. Everything compiles and links ok. But then when I'm trying to step into a function with the debugger - it shows an incorrect code line.

What's interesting is that the difference between the correct line number and the one the debugger shows is exactly 65536. This makes me suspect (almost be sure in) some unsigned short overflow.

I also suspect that it's not a bug in the MSVC itself. Perhaps it's the limitation of the debug information format. That is, the debug information format used by MSVC stores the line numbers as 2-byte shorts.

Is there anything can be done about this (apart from cutting the huge file into several smaller ones) ?

+6  A: 

According to a MS moderator, this is a known issue with the debugger only (the compiler seems to handle it fine as you pointed out). There is apparently no workaround, other than using shorter source files. See official response to very similar question here

Dusty
A: 

If you look at the documentation for the symbolic debugging info, you will see the type used for line numbers. For example, both line and column parameters for IDiaSession::findLinesByLinenum are of type DWORD.

Edit: As @valdo points out, that still doesn't mean the debugger works properly with huge line numbers. So you have to use shorter files. It is unfortunate that such limitation exists, but even if there wasn't I'd still recommend you split your source.

Franci Penov
Well, let me disagree. The even fact the IDiaSession/IDialSession interfaces are declared with DWORD parameters doesn't mean that the *actual* debug information stored with DWORD line numbers. The interface may just be designed to support larger line numbers, not necessarily it's implemented.
valdo
A: 

Unless you are modifying SQLite, you should just trust that it is doing its job. No need to step in at all. SQLite is run through a large battery of tests before release.

gbrandt
Editorialization like this should probably be a comment on the question. This doesn't attempt to answer the OP's question, or the general issue inherent in it.
quixoto
A: 

Have you looked into using WinDBG instead? It's pretty capable as the Windows team use it for debugging the O/S and there's some biiiig files in there, or at least there was when I last looked.

JBRWilkinson
Not yet. However, as I said, it seems to be the limitation of the debug information format, not some bug in the debugger
valdo