#133 custom File Type association for .vcproj, Project Importer, CRASH w/ SIGSGEV

[Melchior]

I created a custom File Type association for
- .vcproj label:"Project File (MS Visual C++)(v7.0+)"

using existing Code::Block entries as a template...
(loading from batch file archives the same result as well.)

Project File (MS Visual C++)(v7.0+)
C:\Dev-CodeBlocks\codeblocks.exe "%1"
[Open("%1")]
CODEBLOCKS
[IfExec_Open("%1")]
CodeBlocksDDEServer

1) ^^Create File Type association^^ or skip to 2) and run via .cmd batch file:

on WinXP 
Windows Explorer --> Tools --> Folder Options --> File Types. new

• vcproj label:"Project File (MS Visual C++)(v7.0+)"

a Program called Types ^_^ can also be used to create
custom file type association manually
(especially on Win7(default app ONLY)
and newer where the old File Types editor NO LONGER EXISTS)
"Types allows you to customize the way Windows handles different file types:
set program associations, change icons, context menus and other properties. "
http://izt.name/apps/types/
http://izt.name/apps/types/new.rss <-- ChangeLog newsfeed
requires .NET v2 or newer

2)
either double click the "Notepad2.vcproj"(step 1) FILE or run the batch file..

after C::B loads and comes up
- OK, compiler selection popup
- OK, Build Target import

Confirmation (POPUP)
Project file already exists.
Are you really sure you want to OVERWRITE it?
(apparently C::B creates the cbp file shortly after it loads the .vcproj file.

OK, that overwrite ^
REPEATs --> compiler select, OK
REPEATs --> build target import, OK.. THEN IT CRASHES!

---

I have included a RAR archive with a copy of includes
- Notepad 2's src,
- scintilla src, and the
- .cmd batch file I created for debugging(gdb) Code::Blocks
while loading "Notepad2.vcproj"
(customize to your system layout!)
- Debugging (gdb)_CodeBlocks__gdb Logs.txt

on a side note this bug was probably never noticed because C::B devs never actually added .vcproj to the file type associations internally

gdb log:
http://dpaste.com/33A7RQE <-- Full gdb log
http://dpaste.com/1JEECQY <-- SIGSEGV & BackTrace

[Melchior]

Program received signal SIGSEGV, Segmentation fault.
0x0113e9c0 in wxArrayString::Index (this=0x149601d8, sz=0x149a609c L"Release Win32", bCase=true, bFromEnd=false)
at ../../src/common/string.cpp:2380
2380 res = wxStrcmp(sz, m_pItems[i]);

[Melchior]

[ollydbg]

1, I download the rar file, and unzip.
2, I open C::B, and click the menu->File->Import projects->Visual Studio projects.
3, I select the Notepad2.vcproj
4, I don't have crash when importing

Do you mean the crash open happens when you set the File Type association and then double click on the Notepad2.vcproj?

[Melchior]

Importing done via C::B's internal menu's no problem

...yes! I take it you didn't read my rather long winded post.. loi ;D

batch file or File Type association, it works the same way in the backend like a cmdline...

I had included a .cmd file for convenience... you will just have to edit for the location of your C::B install/nightly/src dir(s)

gdb log:
http://dpaste.com/33A7RQE <-- Full gdb log
http://dpaste.com/1JEECQY <-- SIGSEGV & BackTrace

[bluehazzard]

hmm i have tried to replicate your crash, but i wasn't able to recreate it.

can you look if "sz" is null terminated (best if you look in the memory dump)?

[Melchior]

The Dr.Watson logs have blank spaces where ?? where the fault is,...
I haven't got around to making gdb make dumps it can use...

and the memory dump wasn't much helpful i did not see a sz register...

trying WinDbg

320.ad8): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

wxmsw28ud_gcc_custom!ZNK12wxStringBase13GetStringDataEv+0xc:

016aba38 8b00 mov eax,dword ptr [eax] ds:002b:00000000=????????

trying gdb again form command line brb will update post shortly

Program received signal SIGSEGV,
Segmentation fault.

0x0113e9c0 in wxArrayString::Index
(
this=0x14b2a180,
sz=0x14b46bfc L"Release Win32",
bCase=true, bFromEnd=false
)
at ../../src/common/string.cpp:2380
2380 res = wxStrcmp(sz, m_pItems[i]);

.....OOHH now I remember string have or should be NULL terminated '\0'

so that info wasn't in the log I linked above?.....

_<!! I tried various dump cmds but I can't seem to get the

dump memory FILE=codeblocks.dmp START=address STOP=address

this is stupid..
gdb is way to complicated for memory dumping...

if you can help me with some memory dumping instructions I'll try again later dinner is probably burning lol ;D

[Melchior]

I finally figured out how to run it through C::B..
loaded CB Projects file, start debugger, give it the additional CMDline parameter "F:\Dev-src\Notepad2(v4.2.25)_src\Notepad2.vcproj"
and i got a bit more data.

00:35:29: Failed to open 'F:\Dev-src\Notepad2(v4.2.25)_src\Notepad2.cbp' for reading (error 2: the system cannot find the file specified.)

00:35:29: Failed to retrieve file times for 'F:\Dev-src\Notepad2(v4.2.25)_src\Notepad2.cbp' (error 2: the system cannot find the file specified.)

a popup in the debugger/C::B [ Selected Frame ]:
http://dpaste.com/28Z0QBF

CodeBlocks Back Trace & Memory map
http://dpaste.com/197YEJ6

---

now I remember!

res = wxStrcmp(sz, m_pItems[i]);

s = string
z = NULL
so
sz = NULL terminated string.

[bluehazzard]

s = string
z = NULL
so
sz = NULL terminated string.

this must be a new feature in c++. I never saw two variable combine without operator ;)
according the memory dump the string is null terminated, so the error has to be in m_index[i] probably i is out of bounce... i will retry to recreate the bug...

[Melchior]

ah.. I don't know about new feature.. just nomanclature
how variables and functions are named to make them more clear

like prefixing lp to indicate a long pointer type variable

LPSTR lpszArgument <<-- lpsz a A NULL terminated,
Long Pointer type string variable

HINSTANCE hThisInstance <<-- h, handle variable

both sued to NULL terminate a string... pretty sure '\0' for certain.
\z
\0

[bluehazzard]

I was able to recreate the crash.
I think the problem is here:

sdk\projectfile.cpp: 80
void ProjectFile::AddBuildTarget(const wxString& targetName)

    if (buildTargets.Index(targetName) == wxNOT_FOUND)
        buildTargets.Add(targetName);

buildTargets is not initialized (the size is invalid). This gets called from:
plugins\projectsimporter\msvc7loader.cpp: 640
bool MSVC7Loader::DoImportFiles(TiXmlElement* root, int numConfigurations)

~~~~~~~~
ProjectFile* pf = m_pProject->AddFile(0, fname);
if (pf)
{
// add it to all configurations, not just the first
for (int i = 1; i < numConfigurations; ++i)
{
pf->AddBuildTarget(m_pProject->GetBuildTarget(i)->GetTitle());
HandleFileConfiguration(file, pf); // We need to do this for all files
}
}

i suspect that pf is a false pointer. The pf isn't newly created, but returned by:
sdk\cbproject.cpp:645
_ProjectFile* cbProject::AddFile(int targetIndex, const wxString& filename, bool compile, bool link, cb_unused unsigned short int weight)_

ProjectFile* pf = m_ProjectFilesMap[UnixFilename(filename)];
if (pf)
    return pf;

~~~~~~~~~~

so probably the hash map has a problem to locate the file?

[bluehazzard]

i have tried a lot (and probably found a bug in the valgrind plugin) but could not solve this.... Probably someone other can find out more...

[Teodor Petrov]

bluehazzard: Have you tried to place a break point on the line before the crash and then inspect the values of the variables?

[bluehazzard]

pf is definitely out of address. The files before crash had addresses like
0x1223d438
0x1223dc98
....
0x1224xxxx
but at the crash bf had the address: 0x6dd9750
i have replaced the [] operator of the hash table with find and an iterator and the same results happened...

[Melchior]

loi so we have made a bit of progress ^^,
that's enough to put even a small smile on my face ^^

[Melchior]

ok I got a bit more info to post...

these errors popup after the compiler selection when it asks to overwrite a file it hasn't yet created..

22:47:55: Failed to open 'F:\Dev-src\Notepad2(v4.2.25)_src\Notepad2.cbp'
for reading (error 2: the system cannot find the file specified.)

22:47:55: Failed to retrieve file times for 'F:\Dev-src\Notepad2(v4.2.25)_src\Notepad2.cbp'
(error 2: the system cannot find the file specified.)

these two repeat as a pair another 7 or so times...

ok overwrite, ok 2nd time on compiler select and it crash just like before..

ps: compiled from latest src

[Melchior]

Has anyone else taken a look at this bug yet?

[Melchior]

bump! I tried looking at it myself.... just I have never worked on anything this large... my own program is a simple console app Temperature converter

[Teodor Petrov]

This issue should be fixed in trunk. Please test and report if it really is.

[Melchior]

I will svn update later when I get home but that looks like it just might have fixed it ^_^

TY!
go figure its not Project Importer but the way C::B was handling the file open via cmdline. O_o

[Teodor Petrov]

It is possible that there is another bug in the projects importer. Do you have two different vcproj files? If you have can you pass them to cb simultaneously and see if it crashes?

[Melchior]

at the same time...? no just one for that project,
but I can try loading for that other project...

• Notepad 2 (Text editor)
  -- Notepad2.vcproj <-- VC++ v7 Project File

• Project64 (N64 Emulator)
  -- Project64.vcxproj <-- VC++ v12 Project File
  -- Project64.dsp .... <-- VC++ v6 Project File
  -- Project64.vcproj . <-- VC++ v9 Project File

[Melchior]

Teodor Petrov,
your fix works ^_^!

Now for testing the import of the other projects files from PJ64...

Project64.dsp, VC++ v6:
Importing F:\Dev-src\2Emulators\Project64\Source\Project64\Project64.dsp:
NativeParser::CreateParser(): Finish creating a new parser for project 'Project64'
NativeParser::OnParserEnd(): Project 'Project64' parsing stage done!

Project64.vcproj, VC++ v9:
Importing F:\Dev-src\2Emulators\Project64\Source\Project64\Project64.vcproj:
NativeParser::CreateParser(): Finish creating a new parser for project 'Project64'
NativeParser::OnParserEnd(): Project 'Project64' parsing stage done!

Project64.vcxproj, VC++ v12:
Importing F:\Dev-src\2Emulators\Project64\Source\Project64\Project64.vcxproj:
it fails, it seems VC++ v12+ is not supported in Code::Blocks