Valgrind error with std::cin - c++

Here is my code:
std::string getword()
{
std::string temp;
std::cin >> temp;
return temp;
}
Valgrind throws an error on the line std::cin >> temp.
Here is the valgrind output for those who asked:
HEAP SUMMARY:
==18490== in use at exit: 33 bytes in 1 blocks
==18490== total heap usage: 397 allocs, 396 frees, 12,986 bytes allocated
==18490==
==18490== 33 bytes in 1 blocks are possibly lost in loss record 1 of 1
==18490== at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18490== by 0x4EEE3B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EEF127: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EEF20F: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x4EA7D14: std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
==18490== by 0x401681: getword() (netsim.cc:29)
==18490== by 0x401F6E: main (netsim.cc:96)
==18490==
==18490== LEAK SUMMARY:
==18490== definitely lost: 0 bytes in 0 blocks
==18490== indirectly lost: 0 bytes in 0 blocks
==18490== possibly lost: 33 bytes in 1 blocks
==18490== still reachable: 0 bytes in 0 blocks
==18490== suppressed: 0 bytes in 0 blocks
==18490==
==18490== For counts of detected and suppressed errors, rerun with: -v
==18490== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
netsim.cc:96 is the second call to getword() in the program. That code reads
std::string network = getword();
netsim.cc:29 is the code for getword() itself. Line 29 is the line
std::cin >> temp
I still don't understand why this happened but I managed to resolve the issue.
I had the code
std::string s = getword();
immediatly above
std::string network = getword();
I made both s and network global variables and somehow the issue was resolved.
If anyone can explain why that is though I would be grateful.

I'm not a valgrind Expert, but I'm tentative to say that this is a false positive. In fact, it might even be a false positive generated by valgrind itself. Looking at the Leak Summary and seeing the core origin of the leak, I get suspicious:
// The one right below this, that's at the top of that valgrind error
==18490== at 0x4C2AF8E: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==18490== by 0x4EEE3B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17)
Now why would valgrind be reporting a memory leak from its own shared library ? Something doesn't seem right here. Either valgrind itself isn't very clean in how its allocating that memory (and valgrind has its own leak! Oh noes!) or it's throwing a really strange false positive. Unless the newest branches of GCC have produced a memory leak for std::string and the istream& operator<< recently, I can't imagine this actually leaking. std::cin and std::cout have been being used for ages, and it makes no sense that valgrind would toss an error over it, especially when your client code isn't making a single new/delete call.
So, in short, there's a few things that could be happening here:
valgrind is leaking. (Maybe? It's originating from a valgrind function)
GCC is leaking? (Hesitant to say this)
valgrind is drunk! :[
In either case, ignore it and move on. I doubt this is going to shatter your netsim in any crucial way.
I hope it clears up soon, and I'm sorry my answer can only say this much, but these are the best shots I can give.

Related

std::string causing memory leaks

I am running into a situation where my application is having memory leaks. After running valgrind, it looks as if I am getting a memory leak related to a std::string:
==20274== 34 bytes in 1 blocks are definitely lost in loss record 34 of 140
==20274== at 0x4C29DB5: operator new(unsigned long) (vg_replace_malloc.c:332)
==20274== by 0x7F843C8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0x7F84DE4: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0x7F84F32: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib64/libstdc++.so.6.0.13)
==20274== by 0xA50CC71: __static_initialization_and_destruction_0(int, int) (filename.cpp:22)
==20274== by 0xA50D03F: _GLOBAL__sub_I_filename.cpp (filename.cpp:112)
==20274== by 0x400E9CE: _dl_init (in /lib64/ld-2.12.so)
==20274== by 0x4000B69: ??? (in /lib64/ld-2.12.so)
The code in question is:
in filename.h:
extern std::string aString;
in filename.cpp:
std::string aString = "a string";
Also worth note, this is in a separate namespace i.e.
namespace aNamespace {
//...
std::string aString; // in extern in .h
//...
}
Every place in code, it is (of course) referenced as:
aNamespace::aString;
And, from what I can tell, it is never reset, and is used either as a constant reference, or to initialize another string.
Can there ever be a situation where std::string would give memory leaks?
edit:
A related portion of the valgrind output:
==20274== by 0x400EFBB: _dl_fini (in /lib64/ld-2.12.so)
==20274== by 0x88DAA01: exit (in /lib64/libc-2.12.so)
==20274== by 0x88C3D26: (below main) (in /lib64/libc-2.12.so)
Is this making an exit call? Is it the standard exit(0)?
Valgrind produces this kind of messages if on program termination there's still some heap-allocated memory, but no variable holds a pointer to.
std::string allocates memory in it's constructor to provide storage for chars. Destructor should free memory back.
My guess is that application is terminated using exit(0) or so. In this case stack does not unwind, and no destructors are called.

valgrind shows memory leak in vector constructor

I am writing a compiler using bison and C++, and I just checked memory leak with Valgrind. While it shows there's memory leak caused by vector constructor shown below:
==6562== HEAP SUMMARY:
==6562== in use at exit: 90,298 bytes in 27 blocks
==6562== total heap usage: 125 allocs, 98 frees, 100,782 bytes allocated
==6562==
==6562== 80 (32 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 19 of 22
==6562== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6562== by 0x40DB9B: __gnu_cxx::new_allocator<std::shared_ptr<Node> >::allocate(unsigned long, void const*) (new_allocator.h:104)
==6562== by 0x40D3B9: std::allocator_traits<std::allocator<std::shared_ptr<Node> > >::allocate(std::allocator<std::shared_ptr<Node> >&, unsigned long) (alloc_traits.h:491)
==6562== by 0x40C465: std::_Vector_base<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > >::_M_allocate(unsigned long) (stl_vector.h:170)
==6562== by 0x41C170: std::_Vector_base<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > >::_M_create_storage(unsigned long) (stl_vector.h:185)
==6562== by 0x41ADB6: std::_Vector_base<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > >::_Vector_base(unsigned long, std::allocator<std::shared_ptr<Node> > const&) (stl_vector.h:136)
==6562== by 0x41A13F: std::vector<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > >::vector(std::vector<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > > const&) (stl_vector.h:320)
==6562== by 0x417ECF: OprNode::OprNode(int, std::vector<std::shared_ptr<Node>, std::allocator<std::shared_ptr<Node> > > const&) (Node.cpp:52)
==6562== by 0x406C7B: opr(int, std::vector<Node*, std::allocator<Node*> > const&) (parser.y:175)
==6562== by 0x40555B: yyparse() (parser.y:125)
==6562== by 0x40748B: main (parser.y:253)
==6562==
==6562== LEAK SUMMARY:
==6562== definitely lost: 32 bytes in 1 blocks
==6562== indirectly lost: 48 bytes in 2 blocks
==6562== possibly lost: 0 bytes in 0 blocks
==6562== still reachable: 90,218 bytes in 24 blocks
==6562== suppressed: 0 bytes in 0 blocks
==6562== Reachable blocks (those to which a pointer was found) are not shown.
==6562== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6562==
==6562== For counts of detected and suppressed errors, rerun with: -v
==6562== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Relevant code:
class Node {
public:
Node()=default;
virtual void ex(int, int, int) const = 0;
virtual void check(vector<int>&, int) const = 0;
};
class OprNode:public Node {
public:
OprNode(int, const vector<shared_ptr<Node>>&);
void ex(int, int, int) const;
void check(vector<int>&, int) const;
private:
int oper;
vector<shared_ptr<Node>> op;
};
OprNode::OprNode(int oper, const vector<shared_ptr<Node> >& op):oper(oper), op(op) {;}
Node * opr(int oper, const vector<Node *>& op) {
auto v = vector<shared_ptr<Node> >();
for (const auto i: op) {
v.push_back(shared_ptr<Node>(i));
}
return new OprNode(oper, v);
}
Due to the limitation of bison, I must use raw pointer as the return type and content of vector passed into opr.
Thanks a lot!

valgrind detects errors when c++ exception is not caught

I notice that the valgrind reports possible memory leak for the following minimal example:
#include <stdexcept>
int main() {
try {
throw std::logic_error("test");
}
catch (std::exception& e) {
std::string msg("test2 ");
msg.append(e.what());
throw std::logic_error(msg);
}
return 0;
}
After compiling it with g++ test.cpp -g, the valgrind detects some errors with valgrind --tool=memcheck --leak-check=full ./a.out. Is this normal?
I concern this issue because the valgrind reports some errors of my R extensions which is similar to this example.
The valgrind version is: 3.10.0.SVN. The gcc version is 4.8.2 (Ubuntu 4.8.2-19ubuntu1). The reported message is shown below:
==8640== Memcheck, a memory error detector
==8640== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8640== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==8640== Command: ./a.out
==8640==
terminate called after throwing an instance of 'std::logic_error'
what(): test2 test
==8640==
==8640== HEAP SUMMARY:
==8640== in use at exit: 354 bytes in 4 blocks
==8640== total heap usage: 6 allocs, 2 frees, 417 bytes allocated
==8640==
==8640== 29 bytes in 1 blocks are possibly lost in loss record 1 of 4
==8640== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF2AE0: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF2EF7: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400BA7: main (test.cpp:4)
==8640==
==8640== 37 bytes in 1 blocks are possibly lost in loss record 2 of 4
==8640== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4EF13B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF1F7A: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF2013: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x4EF225E: std::string::append(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400CC6: main (test.cpp:8)
==8640==
==8640== 144 bytes in 1 blocks are possibly lost in loss record 3 of 4
==8640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400B83: main (test.cpp:4)
==8640==
==8640== 144 bytes in 1 blocks are possibly lost in loss record 4 of 4
==8640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8640== by 0x4E944E2: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==8640== by 0x400CD0: main (in /home/wush/Test/a.out)
==8640==
==8640== LEAK SUMMARY:
==8640== definitely lost: 0 bytes in 0 blocks
==8640== indirectly lost: 0 bytes in 0 blocks
==8640== possibly lost: 354 bytes in 4 blocks
==8640== still reachable: 0 bytes in 0 blocks
==8640== suppressed: 0 bytes in 0 blocks
==8640==
==8640== For counts of detected and suppressed errors, rerun with: -v
==8640== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 1 from 1)
Aborted (core dumped)

getline() valgrind memory leak

I am getting a memory leak with getline, and I am not sure why or how to stop it.
Here is the report from valgrind:
==26681==
==26681== HEAP SUMMARY:
==26681== in use at exit: 1,756 bytes in 73 blocks
==26681== total heap usage: 223 allocs, 150 frees, 15,523 bytes allocated
==26681==
==26681== 28 bytes in 1 blocks are possibly lost in loss record 1 of 4
==26681== at 0x4A075BC: operator new(unsigned long) (vg_replace_malloc.c:298)
==26681== by 0x4CCC4B8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (new_allocator.h:94)
==26681== by 0x4CCD227: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (basic_string.tcc:631)
==26681== by 0x4CCD30F: std::string::reserve(unsigned long) (basic_string.tcc:512)
==26681== by 0x4CCD5D4: std::string::append(char const*, unsigned long) (basic_string.tcc:310)
==26681== by 0x4C86384: std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) (istream.cc:397)
==26681== by 0x4026ED: main (test.cpp:210)
==26681==
==26681== LEAK SUMMARY:
==26681== definitely lost: 0 bytes in 0 blocks
==26681== indirectly lost: 0 bytes in 0 blocks
==26681== possibly lost: 28 bytes in 1 blocks
==26681== still reachable: 1,728 bytes in 72 blocks
==26681== suppressed: 0 bytes in 0 blocks
==26681== Reachable blocks (those to which a pointer was found) are not shown.
==26681== To see them, rerun with: --leak-check=full --show-reachable=yes
==26681==
==26681== For counts of detected and suppressed errors, rerun with: -v
==26681== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Here is line 210 of test.cpp
bool pending = getline(inputfile, line);
Some more lines:
string line;
bool pending = getline(inputfile, line);
int round = readOption(inputfile);
int num = readOption(inputfile);
I think it has something to do with when getline fails, and because line is a string it somehow never deallocates that memory. How do I prevent this?
readOption also uses getline but I think it has no memory leaks because string line is defined locally and then goes out of scope, effectively cleaning the memory?
Edit 1:
I have "solved" the issue by making a dummy function :
bool getnewline(ifstream &inputfile) {
string line;
return getline(inputfile, line);
}
However it seems stupid to do this, I am not sure why valgrind is complaining if there is no leak. I am still after a better/clean solution to this issue.
When you exit a C++ program by calling the exit() function, the object destructors are not run. This can result in Valgrind reporting memory leaks.
I know this is almost a year old but I came upon this answer looking specifically for a getline() memory leak issue and want to give minimum instructions on how I was able to reproduce this specific issue, as I think it just comes from defining a std::string variable and not exiting cleanly from the program.
Given the following:
leaky.cpp:
#include <iostream>
int main(int argc, char ** argv) {
std::string x = "x";
exit(1);
return 0;
}
Compile string:
g++ -g -Wall -Wpedantic --std=gnu++11 leaky.cpp -o leaky
Valgrind invocation:
valgrind --tool=memcheck --leak-check=full ./leaky
Doing this will reveal that there is indeed a leak:
==4434== Memcheck, a memory error detector
==4434== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4434== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==4434== Command: ./leaky
==4434==
==4434==
==4434== HEAP SUMMARY:
==4434== in use at exit: 16 bytes in 1 blocks
==4434== total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==4434==
==4434== 16 bytes in 1 blocks are possibly lost in loss record 1 of 1
==4434== at 0x402A6DC: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4434== by 0x40F8213: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x40FA125: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x40FA7AF: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==4434== by 0x804875E: main (leaky.cpp:3)
==4434==
==4434== LEAK SUMMARY:
==4434== definitely lost: 0 bytes in 0 blocks
==4434== indirectly lost: 0 bytes in 0 blocks
==4434== possibly lost: 16 bytes in 1 blocks
==4434== still reachable: 0 bytes in 0 blocks
==4434== suppressed: 0 bytes in 0 blocks
==4434==
==4434== For counts of detected and suppressed errors, rerun with: -v
==4434== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
And of course to try to include an answer to the question, exit(1) forces the program to quit without invoking any destructors, as far as I know--I've only been using C++ for a month and a half, so I'm not really an expert.
Perhaps the C++ class in question is doing something with pointers that suggests possibly leaky behavior to Valgrind.
I get diagnostics about this in a project in which I allocate some arrays, but then I adjust the pointer to the third element so that indices [-2] and [-1] are used to store some meta-information. There is no leak because I restore the pointer and free the arrays correctly.
Valgrind sees that the objects are referenced, however, that they are not referenced "nicely" via pointers to their base address, but only via interior pointers. It looks like a possible leak since no pointer exists for freeing the object.
A situation like this could happen in leaky programs: programs that, say, allocate a big object, give pieces of it (via pointers) to other modules, and then leak the big object. Interior pointers do suggest a leak.
It could be that getline is chummy with the representation of basic::string<> and does something of that sort. When you copy the object, the new object doesn't do anything funny: it just references the string data by its base address. The old object is gone, and it freed the data.
Just a hypothesis.
By the way, in that aforementioned program, I fixed things for Valgrind by retaining an extra pointer to the base address in the vector objects managing those arrays. This extra pointer is only present when the software is built for Valgrind debugging (along with other features, like use of the Valgrind client request API).

Memory Leak using C++ Exceptions

I'm struggling to write a little file handle class in C++11.
I know there already is a lot in the STL to actually handle files, but for learning purposes I wanted to do this by myself.
Unfortunately I don't seem understand, what effect exceptions have on the memory leakage behavior of a C++ program because Valgrind tells me, there are 2 memory leaks in following code:
file.h
#ifndef FILE_H
#define FILE_H
#include <iostream>
#include <memory>
#include <string>
#include <stdio.h>
class FileDeleter {
public:
void operator()(FILE *p);
};
class File {
public:
File(const std::string path);
private:
const std::string _path;
std::unique_ptr<FILE, FileDeleter> _fp;
};
#endif // FILE_H
file.cpp
#include <cstring>
#include <iostream>
#include <stdexcept>
#include <utility>
#include <stdio.h>
#include "file.h"
void FileDeleter::operator()(FILE *p)
{
if (!p)
return;
if (fclose(p) == EOF)
std::cerr << "FileDeleter: Couldn't close file" << std::endl;
}
File::File(const std::string path)
: _path(std::move(path)),
_fp(fopen(_path.c_str(), "a+"))
{
if (!_fp)
throw std::runtime_error("Couldn't open file");
}
main.cpp
#include <cstdlib>
#include "file.h"
int main()
{
File my_file("/root/.bashrc");
return EXIT_SUCCESS;
}
I did choose to open /root/.bashrc on purpose to actually make the File ctor throw the exception. If I don't throw there, Valgrind is perfectly happy.
What am I missing here in using exceptions?
How do you implement a simple file handle "correctly" (exception safe)?
Thanks in advance!
Note: the read/write operations are still missing, since I'm already struggling with the basics.
Edit #1:
This is the actual Valgrind output, using --leak-check=full:
==7998== HEAP SUMMARY:
==7998== in use at exit: 233 bytes in 3 blocks
==7998== total heap usage: 5 allocs, 2 frees, 817 bytes allocated
==7998==
==7998== 38 bytes in 1 blocks are possibly lost in loss record 1 of 3
==7998== at 0x4C27CC2: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7998== by 0x4EEC4F8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x4EEDC30: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x4EEE047: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x40137D: main (in ../a.out)
==7998==
==7998== 43 bytes in 1 blocks are possibly lost in loss record 2 of 3
==7998== at 0x4C27CC2: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7998== by 0x4EEC4F8: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x4EEDC30: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x4EEE047: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x400EBF: File::File(std::string) (in /home/frank/3Other/Code/Laboratory/c++/c++namedpipe/a.out)
==7998== by 0x401390: main (in ../a.out)
==7998==
==7998== 152 bytes in 1 blocks are possibly lost in loss record 3 of 3
==7998== at 0x4C27730: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7998== by 0x4E8F8F2: __cxa_allocate_exception (in /usr/lib/libstdc++.so.6.0.18)
==7998== by 0x400E9B: File::File(std::string) (in /home/frank/3Other/Code/Laboratory/c++/c++namedpipe/a.out)
==7998== by 0x401390: main (in ../a.out)
==7998==
==7998== LEAK SUMMARY:
==7998== definitely lost: 0 bytes in 0 blocks
==7998== indirectly lost: 0 bytes in 0 blocks
==7998== possibly lost: 233 bytes in 3 blocks
==7998== still reachable: 0 bytes in 0 blocks
==7998== suppressed: 0 bytes in 0 blocks
Edit #2:
Fixed exception thrown in Destructor.
Edit #3:
Removed FileException class, using std::runtime_error instead.
Edit #4:
Added NULL check in deleter.
I see the following problems:
fclose(NULL) is not allowed ...
but fortunately std::unique_ptr doesn't call the deleter if get() == nullptr, so this should be ok here
FileDeleter:operator() is called from a destructor, which means it should never throw. In your specific case, any error returned from fclose will cause std::terminate to be called
your exception should store the string by value, not reference. That reference is to a temporary which will have been destroyed by the time you call what().
As Vlad & Praetorian pointed out, you can remove the buggy code instead of fixing it, and just let std::runtime_error handle that for you. TBH, unless you're planning to add some file-specific data to the exception, or you plan to catch file exceptions separately, you don't need this class at all.
Edit: with the valgrind output provided, it looks like stack unwinding never completed. Since my initial thought about FileDeleter::operator() being called and throwing looks wrong, a reasonable test would be: what happens if you stick a try/catch inside the body of main?
General notes:
never throw an exception inside a destructor
never call something else that might throw, from a destructor
because if your destructor is invoked during exception handling/stack unwinding, the program will terminate instantly.