GMP mpf functions causing a segmentation fault - c++

I can not figure out that is causing this error. I just installed GMP on ubuntu. This is a 64 bit OS on an AMD cpu (not sure if it matters). I keep getting a segmentation fault.
#include <stdio.h>
#include <stdlib.h>
#include <gmp.h>
#include <time.h>
int main(int argc, char** argv)
{
mpz_t sum, fac;
mpf_t fsum, ffac;
int i;
time_t t;
mpz_init_set_ui(sum, 1);
mpz_init_set_ui(fac, 1);
t = time(NULL);
for(i = 10000; i >= 1; --i)
{
mpz_mul_ui(fac, fac, i);
mpz_add(sum, sum, fac);
if(i % 10000 == 0)
{
printf("%d\n", i);
}
}
printf("Time %d\n", (time(0) - t));
mpf_init(fsum);
mpf_init(ffac);
mpf_set_z(fsum, sum);
mpf_set_z(ffac, fac);
mpz_clear(sum);
mpz_clear(fac);
mpf_div(fac, sum, fac);
mpf_out_str(stdout, 10, 50, fac);
mpf_clear(fsum);
mpf_clear(ffac);
return(EXIT_SUCCESS);
}
This code outputs the following...
10000
Time 0
Segmentation fault (core dumped)
I then tried to run this program with valgrind and this is the output.
==25427== Memcheck, a memory error detector
==25427== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==25427== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==25427== Command: /home/chase/NetBeansProjects/GmpECalc/dist/Debug/GNU-Linux-x86/gmpecalc
==25427==
10000
Time 1
==25427== Invalid read of size 8
==25427== at 0x4E8E590: __gmpn_copyi (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.1.3)
==25427== by 0x400B27: main (main.c:40)
==25427== Address 0x73b0000073c is not stack'd, malloc'd or (recently) free'd
==25427==
==25427==
==25427== Process terminating with default action of signal 11 (SIGSEGV)
==25427== Access not within mapped region at address 0x73B0000073C
==25427== at 0x4E8E590: __gmpn_copyi (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.1.3)
==25427== by 0x400B27: main (main.c:40)
==25427== If you believe this happened as a result of a stack
==25427== overflow in your program's main thread (unlikely but
==25427== possible), you can try to increase the size of the
==25427== main thread stack using the --main-stacksize= flag.
==25427== The main thread stack size used in this run was 8388608.
==25427==
==25427== HEAP SUMMARY:
==25427== in use at exit: 48 bytes in 2 blocks
==25427== total heap usage: 3,706 allocs, 3,704 frees, 27,454,096 bytes allocated
==25427==
==25427== LEAK SUMMARY:
==25427== definitely lost: 0 bytes in 0 blocks
==25427== indirectly lost: 0 bytes in 0 blocks
==25427== possibly lost: 0 bytes in 0 blocks
==25427== still reachable: 48 bytes in 2 blocks
==25427== suppressed: 0 bytes in 0 blocks
==25427== Rerun with --leak-check=full to see details of leaked memory
==25427==
==25427== For counts of detected and suppressed errors, rerun with: -v
==25427== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
The error seems to be occurring at the mpf_div function. However, if I remove this function the error will occur at mpf_out_str. I also tried initializing ffac and fsum to doubles (instead of setting them to the fac and sum) and I get the same error.

Problem is in this lines:
mpz_clear(sum); // You clear the variables, GMP deallocates their memory
mpz_clear(fac);
mpf_div(fac, sum, fac); // You use cleared variables, segfault
Maybe you meant:
mpf_div(ffac, fsum, ffac);

Related

throw() with clang++ shows possible memory leak

I have a piece of code, which when compiled with g++ does not show any memory leaks.
Whereas, the same when compiled with clang++ shows, possible memory leak.
Here's the trace,
==7115==
==7115== HEAP SUMMARY:
==7115== in use at exit: 16 bytes in 1 blocks
==7115== total heap usage: 2,324 allocs, 2,323 frees, 2,166,060 bytes allocated
==7115==
==7115== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==7115== at 0x4C2BFB9: calloc (vg_replace_malloc.c:762)
==7115== by 0x4129830: __cxxabiv1::__calloc_with_fallback(unsigned long, unsigned long) (in /opt/xxx/lib64/libc++abi.so.1)
==7115== by 0x4128946: __cxa_get_globals (in /opt/xxx/lib64/libc++abi.so.1)
==7115== by 0x412B287: __cxa_throw (in /opt/xxx/lib64/libc++abi.so.1)
==7115== by 0x4E712AE: Lib::GenCmd::RaiseException(Status, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >) (LibBase.cpp:291)
==7115==
==7115== LEAK SUMMARY:
==7115== definitely lost: 0 bytes in 0 blocks
==7115== indirectly lost: 0 bytes in 0 blocks
==7115== possibly lost: 0 bytes in 0 blocks
==7115== still reachable: 16 bytes in 1 blocks
==7115== suppressed: 0 bytes in 0 blocks
==7115==
==7115== For counts of detected and suppressed errors, rerun with: -v
Well, its not possible to share the code snippet, but I can tell you RaiseException() is the function where I have a call made to throw() (at line 291) an exception. Here's the function snippet:
void GenCmd::RaiseException(Status status, std::string AdditionalMsg) throw(Status) {
s_last_error = GetStatusString(status);
if (false == AdditionalMsg.empty()) {
s_last_error = s_last_error + AdditionalMsg;
}
throw(status);
}
Status is a structure, defined as below (along with default, parameterized & copy constructors)
typedef struct _Status {
const u64_t m_status : 8;
const u64_t ReservedByte1 : 8;
const u64_t m_action : 8;
const u64_t ReservedByte3 : 5;
const u64_t m_testbit1 : 1;
const u64_t m_testbit2 : 1;
const u64_t m_cmd_failure : 1;
const u64_t m_module_code : 4;
const u64_t m_file_code : 8;
const u64_t ReservedByte7 : 4;
const u64_t m_line_no : 16;
}Status
The fact, that no leaks are seen with GCC, but only with Clang makes me think this to be some issue with Clang. (With Clang, I mean it could be libcxxabi as well)
I was navigating through the source for clang, & __cxa_get_globals() is the function where a calloc() call is made. I am not yet sure of the execution flow for clang.
Any idea or any inputs which could confirm this to be a Clang issue & not my code issue?
Here's the clang version I am using. The code is compiled with C++11, additionally with '-stdlib=libc++, '-lc++', '-lc++abi'.
[user~]$ clang --version
clang version 7.1.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Update: This exception is raised from the constructor.
Update
I wrote another dummy code to see the behaviour with Clang, & it seems the issue is actually with the Clang (libc++abi).
Have a look at the below naive code
#include <iostream>
#include <stdexcept>
class Positive {
int m_number1;
public:
Positive() : m_number1(10) {
}
Positive(int no) {
if (no < 0) {
// throw 100;
throw std::invalid_argument("Send positive nu");
} else {
m_number1 = no;
}
}
~Positive() {
}
void print() {
std::cout<< "Value of member is: " <<m_number1 <<std::endl;
}
};
int main() {
try {
Positive p1;
p1.print();
Positive p2(100);
p2.print();
Positive p3(-10);
p3.print();
} catch(...) {
std::cout << "Some Exception occured" <<std::endl;
}
return 0;
}
Even on executing the above code, I saw the same result on Valgrind. Here's the output:
[user]$ valgrind --leak-check=full --leak-resolution=high --show-leak-kinds=all ./a.out
==119789== Memcheck, a memory error detector
==119789== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==119789== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==119789== Command: ./a.out
==119789==
Value of member is: 10
Value of member is: 100
Some Exception occured
==119789==
==119789== HEAP SUMMARY:
==119789== in use at exit: 16 bytes in 1 blocks
==119789== total heap usage: 3 allocs, 2 frees, 201 bytes allocated
==119789==
==119789== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==119789== at 0x4C2BFB9: calloc (vg_replace_malloc.c:762)
==119789== by 0x40FF830: __cxxabiv1::__calloc_with_fallback(unsigned long, unsigned long) (in /usr/local/lib/libc++abi.so.1.0)
==119789== by 0x40FE946: __cxa_get_globals (in /usr/local/lib/libc++abi.so.1.0)
==119789== by 0x4101287: __cxa_throw (in /usr/local/lib/libc++abi.so.1.0)
==119789== by 0x4014B0: Positive::Positive(int) (in /home/user/test/a.out)
==119789== by 0x4010F9: main (in /home/user/test/a.out)
==119789==
==119789== LEAK SUMMARY:
==119789== definitely lost: 0 bytes in 0 blocks
==119789== indirectly lost: 0 bytes in 0 blocks
==119789== possibly lost: 0 bytes in 0 blocks
==119789== still reachable: 16 bytes in 1 blocks
==119789== suppressed: 0 bytes in 0 blocks
==119789==
==119789== For counts of detected and suppressed errors, rerun with: -v
==119789== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[user]$
Interestingly, it shows 3 allocations made. Which I am assuming to be something related to the 3rd object, but how can I ensure that is cleared (or not allocated itself)?
Probably, the same thing can help me fix my original code.
I also found this problem. It actually occurs if your code throws anything at least once, so the simplest reproduction scenario is just running this code:
int
main()
{
try {
throw 42;
} catch (int) {}
}
However, if you throw several times there is still just one 16-bytes "leaked" block (which is not really leaked, since it is still reachable from some global variable). Digging into libc++abi library sources shows that such blocks are actually allocated once per thread to hold some exception processing context, and each one is freed when a thread is destroyed since it uses TLS and have proper destructor registered. So after all, it looks totally safe and is not an issue.

Error was detected while a C++MEX interface was running which crashed Matlab although compiling was successful?

I am wrapping a C++ code into Matlab by using mex C++ interface. Although compiling was successful, Matlab crashes when running the function in the code and I do not what is causing it! I am using Matlab 2019a, and I am using the following code
#include "mex.hpp"
#include "mexAdapter.hpp"
#include "RBergomi.h"
using namespace matlab::mex;
using namespace matlab::data;
class MexFunction : public matlab::mex::Function {
public:
void operator()(matlab::mex::ArgumentList outputs, matlab::mex::ArgumentList inputs) {
Vector H(1);
H= Vector { 0.07};
Vector eta(1);
eta= Vector { 1.9};
Vector rho(1) ;
rho= Vector { -0.9};
Vector T(1) ;
T = Vector { 1.0};
Vector K(1) ;
K= Vector { 1.0 };
double xi = 0.0552;
int N = 2;
long M = 1;
Vector W1(2);
W1= Vector { 1.0, 0.0};
Vector W1perp(2);
W1perp = Vector { 1.0 ,0.0};
RBergomiST Obj=RBergomiST(xi, H, eta, rho, T, K, N, M);
double RB;
price(RB, Obj, W1, W1perp );
outputs[0][0] = RB;
}
void price(double RB, RBergomiST Obj, const Vector& W1, const Vector& W1perp) {
RB=Obj.ComputePayoffRT_single(W1, W1perp);
}
};
For compiling I did
mex -g Bergomi_interface.cpp -lfftw3 RBergomi.cpp ParamTot.cpp BlackScholes.cpp
which went successfully but I have the crash of Matlab and this message when running it.
I tried to check if I have a memory leak with Valgrind and I got this final output after fixing some memory leaks but still Matlab crashes.
==6751== Memcheck, a memory error detector
==6751== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6751== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==6751== Command: ./RBergomi
==6751==
==6751==
==6751== HEAP SUMMARY:
==6751== in use at exit: 72,704 bytes in 1 blocks
==6751== total heap usage: 1,455 allocs, 1,454 frees, 368,936 bytes allocated
==6751==
==6751== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==6751== at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
amd64->linux.so)
==6751== by 0x52C1EFF: ??? (in /usr/lib/x86_64-linux-
gnu/libstdc++.so.6.0.21)
==6751== by 0x40106C9: call_init.part.0 (dl-init.c:72)
==6751== by 0x40107DA: call_init (dl-init.c:30)
==6751== by 0x40107DA: _dl_init (dl-init.c:120)
==6751== by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==6751==
==6751== LEAK SUMMARY:
==6751== definitely lost: 0 bytes in 0 blocks
==6751== indirectly lost: 0 bytes in 0 blocks
==6751== possibly lost: 0 bytes in 0 blocks
==6751== still reachable: 72,704 bytes in 1 blocks
==6751== suppressed: 0 bytes in 0 blocks
==6751==
==6751== For counts of detected and suppressed errors, rerun with: -v
==6751== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

C++ valgrind error message segmentation fault

I'm new to C++ and I'm trying to write an enigma machine simulator. I know I've done something funky with my pointers and I've run it through Valgrind, but I'm not sure what the error messages mean and where to begin fixing it? (What does suppressed mean in the leak summary?)
Here's part of the code where each component is created and where the error occurs.
Enigma::Enigma(int argc, char** argv){
errorCode = NO_ERROR;
plugboard = NULL;
*rotor = NULL; //WHERE THE ERROR OCCURS
reflector = NULL;
rotorCount = 0;
//first check how many rotors there are
if (argc >= 5)
rotorCount = argc - 4;
if (argc <= 4)
errorCode = INSUFFICIENT_NUMBER_OF_PARAMETERS;
//pass files into each component and check if well-formed
if (errorCode == NO_ERROR){
plugboard = new Plugboard(argv[1]);
errorCode = plugboard -> errorCode;
if (errorCode == NO_ERROR){
cout << "Plugboard configuration loaded successfully" << endl;
reflector = new Reflector(argv[2]);
errorCode = reflector -> errorCode;
if (errorCode == NO_ERROR){
cout << "Reflector configuration loaded successfully" << endl;
rotor = new Rotor*[rotorCount];
size_t i = 0;
while (i < rotorCount && errorCode == NO_ERROR) {
rotor[i] = new Rotor (argv[i+3]);
i++;
errorCode = rotor[i]-> errorCode;
//destructor if rotor loading was unsuccessful
if (errorCode != NO_ERROR){
for (int j=0; j<=i; j++)
delete rotor[j];
delete [] rotor;
Here's the Valgrind error message:
reflectors/I.rf rotors/I.rot rotors/II.rot rotors/III.rot rotors/I.pos
==68943== Memcheck, a memory error detector
==68943== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==68943== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==68943== Command: ./enigma plugboards/I.pb reflectors/I.rf rotors/I.rot rotors/II.rot rotors/III.rot rotors/I.pos
==68943==
--68943-- run: /usr/bin/dsymutil "./enigma"
==68943== Use of uninitialised value of size 8
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== Uninitialised value was created by a stack allocation
==68943== at 0x1000007D4: main (main.cpp:11)
==68943==
==68943== Invalid write of size 8
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==68943==
==68943==
==68943== Process terminating with default action of signal 11 (SIGSEGV)
==68943== Access not within mapped region at address 0x0
==68943== at 0x100002598: Enigma::Enigma(int, char**) (enigma.cpp:17)
==68943== by 0x100002F92: Enigma::Enigma(int, char**) (enigma.cpp:12)
==68943== by 0x100000862: main (main.cpp:18)
==68943== If you believe this happened as a result of a stack
==68943== overflow in your program's main thread (unlikely but
==68943== possible), you can try to increase the size of the
==68943== main thread stack using the --main-stacksize= flag.
==68943== The main thread stack size used in this run was 10022912.
==68943==
==68943== HEAP SUMMARY:
==68943== in use at exit: 18,685 bytes in 166 blocks
==68943== total heap usage: 187 allocs, 21 frees, 27,133 bytes allocated
==68943==
==68943== LEAK SUMMARY:
==68943== definitely lost: 0 bytes in 0 blocks
==68943== indirectly lost: 0 bytes in 0 blocks
==68943== possibly lost: 72 bytes in 3 blocks
==68943== still reachable: 200 bytes in 6 blocks
==68943== suppressed: 18,413 bytes in 157 blocks
==68943== Rerun with --leak-check=full to see details of leaked memory
==68943==
==68943== For counts of detected and suppressed errors, rerun with: -v
==68943== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1 from 1)
Segmentation fault: 11
Thanks
Maybe you should take a look at: How do pointer to pointers work in C?
Basically, I see that rotor is a pointer to pointer or possibly an array of pointers (since you initialize *rotor to NULL and later also set rotor[i] = new Rotor).
Make sure you've initialized rotor properly. Is it pointing to a valid object? If not, you cannot expect *rotort = NULL /* or whatever value */; to work.
Basically suppressed means the memory leaks outside of your code in shared libraries.And *rotor = NULL,but it doesn't point to any valid object..

Seg Fault using stacks and queues

I am new to using stacks and queues and I am having memory problems. Could you give me a little insight in what I am doing wrong? This is supposed to be an implementation of a war game using stacks and queues.
#ifndef WAR_H
#define WAR_H
/*
This runWar function runs a game of war between 2 automated players
and returns the number of rounds (both put a card down
once per round) until someone won. An integer is given
as an upper limit to how many rounds a game can go on for.
*/
#include <iostream>
#include <stdlib.h>
#include <stdexcept>
#include <stack>
#include <queue>
#include "deck.h"
using namespace std;
int decide(Card, Card, unsigned int&);
int runWar(unsigned int limit)
{
Deck d;
queue<Card> p1;
queue<Card> p2;
while(d.size() != 0)
{
p1.push(d.getTopCard());
if(d.size() != 0)
{
p2.push(d.getTopCard());
}
}
bool winner = false; //checks if anyone won
unsigned int roundcount = 0; //checks number of comparisons
while(roundcount<limit && winner == false)
{
Card one = p1.front();
Card two = p2.front();
p1.pop();
p2.pop();
if(one.getRank() > two.getRank())
{
roundcount++;
p1.push(one);
p1.push(two);
}
else if(one.getRank() < two.getRank())
{
roundcount++;
p2.push(one);
p2.push(two);
}
else
{
stack<Card> pile;
//3 cards off the top each
bool war_done = false;
while(war_done == false)
{
for(unsigned int w=0; w<3; w++)
{
pile.push(p1.front());
pile.push(p2.front());
p1.pop();
p2.pop();
}
Card p11 = p1.front();
Card p22 = p2.front();
pile.push(p11);
pile.push(p22);
p1.pop();
p2.pop();
if(p11.getRank() > p22.getRank())
{
roundcount++;
while(!(pile.empty()))
{
p1.push(pile.top());
pile.pop();
}
p1.push(one);
p1.push(two);
war_done = true;
}
else if(p11.getRank() > p22.getRank())
{
roundcount++;
while(!(pile.empty()))
{
p2.push(pile.top());
pile.pop();
}
p2.push(one);
p2.push(two);
war_done = true;
}
}
if(p1.empty() || p2.empty())
{
winner = true;
}
}
}
return roundcount;
}
#endif
int main()
{
for(unsigned int i=0; i<19; i++)
{
cout<<runWar(1000)<<endl;
}
return 0;
}
My card and deck classes work find. getTopCard() is basically a pop that returns the top card. getRank() says if it is a 2-Ace. Also, the int main() is in the driver.cpp file.
Valgrind Output:
==3942== Memcheck, a memory error detector
==3942== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3942== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==3942== Command: ./doWar
==3942==
==3942== Conditional jump or move depends on uninitialised value(s)
==3942== at 0x4023BA: runWar(unsigned int) (war.h:77)
==3942== by 0x4016F6: main (doWar.cpp:18)
==3942==
==3942== Conditional jump or move depends on uninitialised value(s)
==3942== at 0x40201B: runWar(unsigned int) (war.h:45)
==3942== by 0x4016F6: main (doWar.cpp:18)
==3942==
==3942== Use of uninitialised value of size 8
==3942== at 0x401FCD: runWar(unsigned int) (war.h:41)
==3942== by 0x4016F6: main (doWar.cpp:18)
==3942==
==3942== Invalid read of size 4
==3942== at 0x401FCD: runWar(unsigned int) (war.h:41)
==3942== by 0x4016F6: main (doWar.cpp:18)
==3942== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3942==
==3942==
==3942== Process terminating with default action of signal 11 (SIGSEGV)
==3942== Access not within mapped region at address 0x0
==3942== at 0x401FCD: runWar(unsigned int) (war.h:41)
==3942== by 0x4016F6: main (doWar.cpp:18)
==3942== If you believe this happened as a result of a stack
==3942== overflow in your program's main thread (unlikely but
==3942== possible), you can try to increase the size of the
==3942== main thread stack using the --main-stacksize= flag.
==3942== The main thread stack size used in this run was 8388608.
==3942==
==3942== HEAP SUMMARY:
==3942== in use at exit: 1,728 bytes in 6 blocks
==3942== total heap usage: 33 allocs, 27 frees, 8,952 bytes allocated
==3942==
==3942== LEAK SUMMARY:
==3942== definitely lost: 0 bytes in 0 blocks
==3942== indirectly lost: 0 bytes in 0 blocks
==3942== possibly lost: 0 bytes in 0 blocks
==3942== still reachable: 1,728 bytes in 6 blocks
==3942== suppressed: 0 bytes in 0 blocks
==3942== Rerun with --leak-check=full to see details of leaked memory
==3942==
==3942== For counts of detected and suppressed errors, rerun with: -v
==3942== Use --track-origins=yes to see where uninitialised values come from
==3942== ERROR SUMMARY: 31 errors from 4 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
Before every 'pop()' check wheather it is empty or not like
If(!p1.empty()){
p1.pop();
}

Glib memory leak using valgrind investigation

I know that there is similiar thread before here about this problem and on this site https://live.gnome.org/Valgrind had been explained, I wrote my simple program below
#include <glib.h>
#include <glib/gprintf.h>
#include <iostream>
int main()
{
const gchar *signalfound = g_strsignal(1);
std::cout << signalfound<< std::endl;
return 0;
}
but when I tried to check using valgrind using this command
G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --leak-resolution=high ./g_strsignal
and here is the result
==30274== Memcheck, a memory error detector
==30274== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==30274== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==30274== Command: ./g_strsignal
==30274== Parent PID: 5201
==30274==
==30274==
==30274== HEAP SUMMARY:
==30274== in use at exit: 14,746 bytes in 18 blocks
==30274== total heap usage: 24 allocs, 6 frees, 23,503 bytes allocated
==30274==
==30274== LEAK SUMMARY:
==30274== definitely lost: 0 bytes in 0 blocks
==30274== indirectly lost: 0 bytes in 0 blocks
==30274== possibly lost: 0 bytes in 0 blocks
==30274== still reachable: 14,746 bytes in 18 blocks
==30274== suppressed: 0 bytes in 0 blocks
==30274== Reachable blocks (those to which a pointer was found) are not shown.
==30274== To see them, rerun with: --leak-check=full --show-reachable=yes
==30274==
==30274== For counts of detected and suppressed errors, rerun with: -v
==30274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I noticed that what was valgrind said "Reachable blocks (those to which a pointer was found) are not shown.". then I try to check the gmem.c
source on corresponding function since I used glib-2.35.4 version. I found following code
gpointer
g_malloc (gsize n_bytes)
{
if (G_LIKELY (n_bytes))
{
gpointer mem;
mem = glib_mem_vtable.malloc (n_bytes);
TRACE (GLIB_MEM_ALLOC((void*) mem, (unsigned int) n_bytes, 0, 0));
if (mem)
return mem;
g_error ("%s: failed to allocate %"G_GSIZE_FORMAT" bytes",
G_STRLOC, n_bytes);
}
TRACE(GLIB_MEM_ALLOC((void*) NULL, (int) n_bytes, 0, 0));
return NULL;
}
And my question is
Is this still a normal situation on where valgrind had said "Reachable blocks (those to which a pointer was found) are not shown.", and I think this statement is refer to the g_malloc function above in which has returning mem a gpointer variable?
If not are there any alternatives to solve, "still reachable: 14,746 bytes in 18 blocks" on what valgrind had said above?
I'm running x86 fedora 18
thanks
It most likely refers to dynamically allocated memory returned by the function g_strsignal().
valgrind says "Reachable blocks....", because a valid pointer(signalfound) still points to the dynamically allocated memory.
If Valgrind finds that a pointer to pointing to dynamic memory is lost(overwritten) then it reports a "definite leak...", Since it can conclusively say that the dynamic block of memory can never be freed. In your case the pointer still points to the block valgrind does not assume it is lost but it assumes it is probably by design.