C++ using getline() prints: pointer being freed was not allocated in XCode - c++

I'm trying to use std:getline() but getting a strange runtime error:
malloc: * error for object 0x10000a720: pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug
This is the code that produces this error:
//main.cpp
#include <iostream>
#include <sstream>
int main (int argc, char * const argv[])
{
std::istringstream my_str("demo string with spaces");
std::string word;
while (std::getline(my_str, word, ' ')) {
std::cout << word << std::endl;
}
return 0;
}
Before each word I get this error. From the comments it seems to be a OSX/XCode specific error. Any hints on that?
Update:
The error is only printed in Debug mode. If I build this code in Release mode everything is fine.
Update 2:
More info on that issue can be found here.
Solution:
Set
_GLIBCXX_FULLY_DYNAMIC_STRING=1
in your Preprocessor Macros in targets info build tab.
System info:
OSX 10.6.2 | XCode 3.2 | g++ 4.2 | debug config for i386

At least one person has reported problems with g++ 4.2.1 on Apple that seem possibly related to yours having to do with an improper configuration of the standard library with the _GLIBCXX_FULLY_DYNAMIC_STRING definition (not that I understand any of what I'm typing here).
You might get a bit of a clue from the newsgroup thread that includes this message:
http://gcc.gnu.org/ml/gcc-bugs/2009-10/msg00807.html

Related

Invalid Arguments Error Using PTHREAD_MUTEX_INITIALIZER In GNU MCU Eclipse

I am using GNU MCU Eclipse 4.7.2-202001271244 with GCC Linaro 7.5.0 (arm-linux-gnueabihf). Both are the latest versions as of now
I set up a simple project that uses pthreads and when I try to use PTHREAD_MUTEX_INITIALIZER I get an error in Eclipse even though g++ compiles it without error. The error from Eclipse is:
Invalid arguments ' Candidates are: () (const
{C:\Download\gcc-linaro-7.5.0-2019.12-i686-mingw32_arm-linux-gnueabihf\arm-linux-gnueabihf\libc\usr\include\bits\pthreadtypes.h:1809}
&) '
Looking at pthreadtypes.h, line 1809 is not even a valid line number
My test code is very simple:
#include <pthread.h>
int main(const int argc, const char* const argv[])
{
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&lock);
return 0;
}
I am pretty confident my project is set up correctly because I can take the g++ generated executable and run it successfully on my ARM processor
Does anyone have any ideas or suggestions on resolving this issue? Any thoughts would be greatly appreciated. I have tried searching for information with no luck

std::endl crashes Windows 8, compiled using MinGW

I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.
#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}
This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.
Has anybody seen this problem.
Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.
Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:
Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()
In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.
I suggest the following experiments:
1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):
#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}
2) Eliminate the exit code by:
int main()
{
return 0;
}
3) No newline at all:
#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}
4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).
I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.

Debug Assertion Fails When Trying to Write to Log4cpp Stream

I'm trying to enable logging with log4cpp in the following way.
class Foo
{
private:
log4cpp::Appender* _logAppender;
log4cpp::Layout* _logAppenderLayout;
}
Foo::Foo()
{
_logAppender = new log4cpp::FileAppender("foo", "logs/bar.log"));
_logAppenderLayout = new log4cpp::BasicLayout();
_logAppender.setLayout(_logAppenderLayout);
log4cpp::Category::getRoot().setPriority(log4cpp::Priority::DEBUG);
log4cpp::Category::getRoot().addAppender(_logAppender);
// Crash on line below.
log4cpp::Category::getRoot().debugStream() << "test";
}
When I get to the line where I try to write "test" to the log, I get a crash that says "Debug Assertion Failed!" The assertion is in f:\dd\vctools\crt_bld_self_64_amd64\crt\src\write.c Line 67. The assert that fails is
fh >= 0 && (unsigned)fh < (unsigned)_nhandle
I have created the logs directory and the bar.log file to make sure it exists. I have also confirmed that both my application and the library were built as 64-bit multithreaded debug DLLs. There was no 64 bit build in the log4cpp source, so I created one based on the 32-bit build configuration. I'm using the latest version of log4cpp.
It is old post, but I guess solution for this problem may be useful for somebody.
Most probably you just forgot to create directory "logs" that is in your code.
This is the problem of closed stream: logger does not auto-create directories for your logs, so, no directory -> no file -> open file failed -> invalid file handler -> exception. You should create directories manually. Macros assertions and no more info is sad.
Just discovered this question and tried to get this assertion.
I have built log4cpp (ver 1.1) library and user1229080's test for Win32 and x64 platforms in MSVC2010 and have got no assertion.
I added few lines to get it compiled, and removed "logs" dir from the file path just to get rid of issues related to absent directories:
#include "stdafx.h"
#include <log4cpp/Category.hh>
#include <log4cpp/FileAppender.hh>
#include <log4cpp/OstreamAppender.hh>
#include <log4cpp/BasicLayout.hh>
class Foo
{
private:
log4cpp::Appender* _logAppender, *_conAppender;
log4cpp::Layout* _logAppenderLayout;
public:
Foo();
};
Foo::Foo()
{
_conAppender = new log4cpp::OstreamAppender("con", &std::cout);
_logAppender = new log4cpp::FileAppender("foo", "bar.log");
_logAppenderLayout = new log4cpp::BasicLayout();
_logAppender->setLayout(_logAppenderLayout);
log4cpp::Category::getRoot().setPriority(log4cpp::Priority::DEBUG);
log4cpp::Category::getRoot().addAppender(_logAppender);
log4cpp::Category::getRoot().addAppender(_conAppender);
// Crash on line below. (but not in msvc2010)
log4cpp::Category::getRoot().debugStream() << "test" << log4cpp::eol;
}
int main(int argc, char* argv[]) {
Foo f;
return 0;
}
Which version of visual c++ you encountered the assertion on?

Xerces-c assertion error

I have downloaded and built Xerces-c on linux:
Linux xxxx 2.6.24.7-server-3mnb #1 SMP Wed Sep 9 16:34:18 EDT 2009 x86_64 Intel(R) Xeon(R) CPU 3065 # 2.33GHz GNU/Linux
Created the simple program:
#include <xercesc/sax2/XMLReaderFactory.hpp>
#include <xercesc/sax2/SAX2XMLReader.hpp>
#include <xercesc/sax2/DefaultHandler.hpp>
#include <xercesc/util/XMLUni.hpp>
//#include <xercesc/validators/common/Grammar.hpp>
XERCES_CPP_NAMESPACE_USE;
int main(int argC, char *argv[])
{
// DefaultHandler handler;
SAX2XMLReader *parser = XMLReaderFactory::createXMLReader();
delete parser;
return 0;
}
compiled it:
g++ -lcurl -o xtest test.cpp /usr/local/lib/libxerces-c.a
successful compile, run it and this is what I get:
./xtest
xtest: xercesc/util/XMemory.cpp:63: static void* xercesc_3_1::XMemory::operator new(size_t, xercesc_3_1::MemoryManager*): Assertion `manager != 0' failed.
Aborted (core dumped)
Anyone have similar experience/successfully built and used this library... how? It's becoming a real pain and apparently it's the only thing for linux that properly validates an XML document against multiple schemas with namespace support (or is it??)
It looks like you forgot to call XMLPlatformUtils::Initialize before using any xerces functionality.
Initialization must be called first in any client code.
Also, don't forget XMLPlatformUtils::Terminate() once you're done with xerces i.e. at the end of the program.
The termination call is currently optional, to aid those dynamically loading the parser to clean up before exit, or to avoid spurious reports from leak detectors.
AFAIR failing to init xerces results in the error you listed.

Xcode 3.2.1 and C++ string fails!

In Xcode 3.2.1 on Mac OS X Snow Leopard, I open a project under:
Command Line Tool of type C++ stdc++.
I have the following simple code:
#include <iostream>
#include <string>
using namespace std;
int main(){
string myvar;
cout << "Enter something: " << endl;
cin >> myvar;
cout << endl << myvar << endl;
return 0;
}
The program compiles fine, and prompts me to "Enter Something". When I type in something, and then press enter, I get the following error:
myproject(766) malloc: *** error for object 0x1000041c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal: “SIGABRT”.
sharedlibrary apply-load-rules all
(gdb)
When compiling on an earlier version of Xcode (3.1.2) on a different computer (opened the project with the 'command line utility' option, which does not exist in 3.2.1), the code runs with NO PROBLEM.
Does anybody know what's going on?
Thanks,
Yuval
As far as I can tell, I'm not experiencing this issue in Release mode for x86_64. But I am seeing the issue in Debug x86_64. If I follow the directions given by Howard in this post, I'm able to get it running in debug mode:
Project -> Edit Active Target ...
Click Build tab
Search for "preprocessor"
Delete _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1
Build and run, you'll notice it works. Another interesting observation is that using __gnu_debug::string (from the <debug/string> header) alone does not trigger the error.
EDIT: from the horses mouth (known issues in XCode 3.2.1)
The default gcc 4.2 compiler is not compatible with the Standard C++ Library Debug Mode. C++ programs compiled with Xcode 3.2 may not work in the Debug configuration. To fix this, set the Compiler Version to 4.0, or edit the Debug configuration’s Preprocessor Macros and remove the entries:
_GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1
You can do this for all projects by navigating to /Developer/Library/Xcode/Project Templates/Application/Command Line Tool/C++ Tool/C++Tool.xcodeproj/ and editing project.pbxproj and deleting the lines around line 138:
"_GLIBCXX_DEBUG=1",
"_GLIBCXX_DEBUG_PEDANTIC=1",
An easier way of accomplishing the same thing: paste these lines at the very beginning of your program (before any #include statements):
#define _GLIBCXX_FULLY_DYNAMIC_STRING 1
#undef _GLIBCXX_DEBUG
#undef _GLIBCXX_DEBUG_PEDANTIC
Obviously, this will only affect the current project.