Thread: _BLOCK_TYPE_IS_VALID error

  1. #1
    Registered User
    Join Date
    Mar 2011
    Posts
    53

    Unhappy _BLOCK_TYPE_IS_VALID error

    Hi,

    I get an unexpected error when debugging my program which is:

    Debug Assertion failed: dbgdel.cpp line:52 Expression: _BLOCK_TYPE_IS_VALID

    I searched the net but i couldn't find the solution which applies to my condition.
    Here's the part i which think contains the error:

    Code:
    char* name;
    DATA_STRUCT curData;
    int id;
    
    id=SendMessage(hListBox,LB_GETCURSEL,NULL,NULL);
    
    name=new char[SendMessage(hListBox,LB_GETTEXTLEN,(WPARAM)id,NULL)+1];
    						
    SendMessage(hListBox,LB_GETTEXT,(WPARAM)id,(LPARAM)name);
    						
    curData=ReadData(name,gSelType);
    						
    SetWindowText(hEditName,curData.name.c_str());
    						
    SetWindowText(hEditInfo,curData.info.c_str());
    						
    delete [] name;
    Code:
    DATA_STRUCT ReadData(char* name,int type)
    {
    	FILE *file;
    	char dir[200]="Data/";
    	DATA_STRUCT rc;
    
    	strcat_s(dir,200,typeItems[type]);
    	strcat_s(dir,200,"/");
    	strcat_s(dir,200, name);
    	strcat_s(dir,200,".dat");
    
    	file=fopen(dir,"r");
    	fread(&rc,sizeof(DATA_STRUCT),1,file);
    	fclose(file);
    
    	return rc;
    }
    Code:
    typedef struct{
    	string name;
    	string info;
    	}DATA_STRUCT;
    i thought of putting this into the windows board, but i'm sure there's sth with the c++ part.

  2. #2
    Registered User
    Join Date
    May 2010
    Posts
    4,633
    So what line is the same as dbgdel.cpp line:52 ?

    Jim

  3. #3
    Registered User
    Join Date
    Mar 2011
    Posts
    53
    Quote Originally Posted by jimblumberg View Post
    So what line is the same as dbgdel.cpp line:52 ?

    Jim
    None of them...

    EDIT: here's dbgdel.cpp, line:52:

    Code:
     
     _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));

  4. #4
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    639
    Quote Originally Posted by jimblumberg View Post
    So what line is the same as dbgdel.cpp line:52 ?
    The one inside the CRT that tries to free the char* that the std::strings contained when they were (presumably) fwritten to the file. OP, look up serialization. fwriting a std::string to the file doesn't save the contents, you need to actually fwrite those using c_str() and length. Alternatively you could drop the C file I/O routines and adopt the shiny C++ fstream ones with their "do the right thing" << and >> operations.

  5. #5
    Registered User
    Join Date
    Mar 2011
    Posts
    53
    Quote Originally Posted by adeyblue View Post
    The one inside the CRT that tries to free the char* that the std::strings contained when they were (presumably) fwritten to the file. OP, look up serialization. fwriting a std::string to the file doesn't save the contents, you need to actually fwrite those using c_str() and length. Alternatively you could drop the C file I/O routines and adopt the shiny C++ fstream ones with their "do the right thing" << and >> operations.
    But ReadData works for some of the files, while the others fail... What's the explanation of this?

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by new_in_c++
    But ReadData works for some of the files, while the others fail... What's the explanation of this?
    Chance, e.g., maybe the contents of the strings were sufficiently small that they were stored in a member char array that was copied, or maybe it so happens that the pointers were restored to point to the same memory.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    If the data that you write contains pointers, then only the value of the pointer gets printed, not the actual data that is being pointed to. If you then later try to read the file, you will read the pointers, but those pointers are no longer pointing to the data (since the data itself is no longer in memory).

  8. #8
    Registered User
    Join Date
    Mar 2011
    Posts
    53
    As far as i understand, everything will be solved if i use fstream, right?

  9. #9
    Registered User
    Join Date
    Dec 2007
    Posts
    2,675
    What a mish-mash of C and C++. Yuck.

    Might I suggest, if you're going to use C I/O, sprintf?

    Code:
    DATA_STRUCT ReadData(char* name,int type)
    {
    	FILE *file;
    	char dir[200]="Data/";
    	DATA_STRUCT rc;
    
    	strcat_s(dir,200,typeItems[type]);
    	strcat_s(dir,200,"/");
    	strcat_s(dir,200, name);
    	strcat_s(dir,200,".dat");
    can be replaced with

    Code:
    DATA_STRUCT ReadData(const char* name,int type)
    {
    	FILE *file = NULL;
    	char dir[PATH_MAX]={ 0 };
    	DATA_STRUCT rc = { 0 };
    
            sprintf(dir, "Data/%s/%s.dat", typeItems[type], name);
            file=fopen(dir,"r");
    	if (file) {
                fread(&rc,sizeof(DATA_STRUCT),1,file);
    	    fclose(file);
            }
            return rc;
    Although I think you should be passing in your DATA_STRUCT and returning a status to your caller, but it seems error checking isn't all that important to you. Not a good trait for a programmer.

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    You propose to turn a safer solution into an error prone one? If you go entirely c++, you should not have to worry about these problems.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Registered User
    Join Date
    Mar 2011
    Posts
    53
    Quote Originally Posted by Elysia View Post
    You propose to turn a safer solution into an error prone one? If you go entirely c++, you should not have to worry about these problems.
    What do you mean by "entirely c++"?

  12. #12
    Registered User
    Join Date
    Dec 2007
    Posts
    2,675
    What's more error-prone about what I provided? Other than I should have used snprintf over sprintf.

    Code:
    snprintf(dir, sizeof(dir), "Data/%s/%s.dat", typeItems[type], name);
    or is it because I didn't use the sainted Windows "safe stdio" calls?

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    You used sprintf over strcat_s, which would make it less safe.
    But why are we bothering with C API in the first place? This is C++. If we want to use sprintf, we can use Boost.Format. Or we can use std::string.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Don't try and do this:
    Code:
    name=new char[SendMessage(hListBox,LB_GETTEXTLEN,(WPARAM)id,NULL)+1];
    Trying to do all that one one line spells trouble. At the very least it means that you're never checking the return value of SendMessage is what you expect.
    What if it's returning -1?!
    Split it over two lines.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 1
    Last Post: 11-15-2010, 11:14 AM
  2. _BLOCK_TYPE_IS_VALID assertion error
    By stanlvw in forum C++ Programming
    Replies: 3
    Last Post: 04-08-2009, 06:13 PM
  3. _BLOCK_TYPE_IS_VALID(pHead -> nBlockUse)
    By andrea72 in forum C++ Programming
    Replies: 2
    Last Post: 06-05-2008, 09:04 AM
  4. Replies: 3
    Last Post: 10-02-2007, 09:12 PM
  5. _BLOCK_TYPE_IS_VALID(phead->nBlockUse)
    By edwardtisdale in forum C++ Programming
    Replies: 1
    Last Post: 12-11-2001, 06:40 PM