I have never seen this. Any chance you could try running in valgrind many times until it happens? e.g. in a while loop :)

On Thursday 16 December 2004 05:02, David Faure wrote:

> I have never seen this. 

My environment is bizarre.  A C++ (QProcess) test running a bash script 
that starts karm and interacts via dcop.

> Any chance you could try running in valgrind 
> many times until it happens? e.g. in a while loop :)

Yes, but probably not for a week or two.  I'll add any findings here.

On Thursday 16 December 2004 05:02, David Faure wrote:
> Any chance you could try running in valgrind
> many times until it happens? e.g. in a while loop :)

No errors, but a couple leaks in /usr/bin/make.  I'll try taking make out 
of the equation.

kdecvs@pooh:~/build/kdepim/karm$ valgrind --leak-check=yes make check
==16950== Memcheck, a memory error detector for x86-linux.
==16950== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==16950== Using valgrind-2.2.0, a program supervision framework for 
x86-linux.

[snip]

libkcal: ResourceCached::calendarIncidenceChanged(): libkcal-219032035.720
@▒¦hÞ@ôÿ¿´@õÿ¿(ùàôÿ¿¶Àôÿ¿8õÿ¿càôÿ¿õÿ¿àôÿ¿ÿàôÿ¿ged(): libkcal-219Pàôÿ¿,ôÿ¿¸ 
¨pôÿ¿Xôÿ¿n@pôÿ¿àôÿ¿4ù%@pôÿ¿àôÿ¿ôÿ¿ßl
~_å@àôÿ¿P▒Áµ@lV@8õÿ¿z-å@° Á@  Á@ à@Á»µ@8  Á@|P­
å@  Á@Áµ@Hõÿ¿¨àöÿ¿Xõÿ¿h¨(Xõÿ¿míU@¬è@¨õÿ¿¡ÓU@¨àõÿ¿²òU@▒õÿ¿wëU@▒¬è@¨õÿ¿rñU@¨▒¬èöÿ¿AÒU@▒àõÿ¿Ý@_¬è@èõÿ¿s-@ÿÿÿÿ▒àõÿ¿ôõÿ¿@¡öÿ¿ÌÉN@öÿ¬è@(öÿ¿@(öÿ¿¬è@¬è@¬è÷ÿ¿!ÂN@`öÿ¿Xöÿ¿  Á@T®­
@àöÿ¿Zì(÷ÿ¿¬è@Xøÿ¿8÷ÿ¿9@
runscripts: running lifetest.php
 OggS-SEEK: at 832 want 47096 got 45248 (diff-requested 46264)

[snip]

=16950== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==16950== malloc/free: in use at exit: 303958 bytes in 11025 blocks.
==16950== malloc/free: 60867 allocs, 49842 frees, 2032198 bytes allocated.
==16950== For counts of detected errors, rerun with: -v
==16950== searching for pointers to 11025 not-freed blocks.
==16950== checked 2104644 bytes.
==16950==
==16950== 28 bytes in 1 blocks are definitely lost in loss record 2 of 8
==16950==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==16950==    by 0x8057350: (within /usr/bin/make)
==16950==    by 0x804B722: (within /usr/bin/make)
==16950==    by 0x805485A: (within /usr/bin/make)
==16950==
==16950==
==16950== 351 bytes in 17 blocks are definitely lost in loss record 4 of 8
==16950==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==16950==    by 0x1B9A88FF: strdup (in /lib/libc-2.3.2.so)
==16950==    by 0x8057400: (within /usr/bin/make)
==16950==    by 0x805B9C1: (within /usr/bin/make)
==16950==
==16950== LEAK SUMMARY:
==16950==    definitely lost: 379 bytes in 18 blocks.
==16950==    possibly lost:   0 bytes in 0 blocks.
==16950==    still reachable: 303379 bytes in 11006 blocks.
==16950==         suppressed: 200 bytes in 1 blocks.
==16950== Reachable blocks (those to which a pointer was found) are not 
shown.
==16950== To see them, rerun with: --show-reachable=yes

On Friday 17 December 2004 16:15, Mark Bucciarelli wrote:

> I'll try taking make out of the equation.

make check was giving that garbage on every run (i tried it three times)

when I ran the tests from a bash script instead of make check, i got no 
garbage after running the script three times in a row.

so i think it's make.

On Friday 17 December 2004 16:15, Mark Bucciarelli wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=95237
>
>
>
>
> ------- Additional Comments From mark hubcapconsulting com  2004-12-17
> 22:15 -------
>
> On Thursday 16 December 2004 05:02, David Faure wrote:
> > Any chance you could try running in valgrind
> > many times until it happens? e.g. in a while loop :)
>
> No errors, but a couple leaks in /usr/bin/make.  I'll try taking make
> out of the equation.
>
> kdecvs pooh:~/build/kdepim/karm$ valgrind --leak-check=yes make check
> ==16950== Memcheck, a memory error detector for x86-linux.
> ==16950== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et
> al. ==16950== Using valgrind-2.2.0, a program supervision framework for
> x86-linux.
>
> [snip]
>
> libkcal: ResourceCached::calendarIncidenceChanged():
> libkcal-219032035.720 ▒¦hÞ ôÿ¿´
> õÿ¿(ùàôÿ¿¶Àôÿ¿8õÿ¿càôÿ¿õÿ¿àôÿ¿ÿàôÿ¿ged(): libkcal-219Pàôÿ¿,ôÿ¿¸
> ¨pôÿ¿Xôÿ¿n pôÿ¿àôÿ¿4ù% pôÿ¿àôÿ¿ôÿ¿ßl
> ~_å àôÿ¿P▒Áµ lV 8õÿ¿z-å ° Á   Á@ à Á»µ 8  Á |P­
> å   Á Áµ Hõÿ¿¨àöÿ¿Xõÿ¿h¨(Xõÿ¿míU ¬è ¨õÿ¿¡ÓU ¨àõÿ¿²òU ▒õÿ¿wëU ▒¬è ¨õÿ¿rñU
> ¨▒¬èöÿ¿AÒU ▒àõÿ¿Ý _¬è èõÿ¿s- ÿÿÿÿ▒àõÿ¿ôõÿ¿ ¡öÿ¿ÌÉN öÿ¬è (öÿ¿ (öÿ¿¬è ¬è
> ¬è÷ÿ¿!ÂN `öÿ¿Xöÿ¿  Á T®­ àöÿ¿Zì(÷ÿ¿¬è Xøÿ¿8÷ÿ¿9@
> runscripts: running lifetest.php
>  OggS-SEEK: at 832 want 47096 got 45248 (diff-requested 46264)
>
> [snip]
>
> =16950== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
> ==16950== malloc/free: in use at exit: 303958 bytes in 11025 blocks.
> ==16950== malloc/free: 60867 allocs, 49842 frees, 2032198 bytes
> allocated. ==16950== For counts of detected errors, rerun with: -v
> ==16950== searching for pointers to 11025 not-freed blocks.
> ==16950== checked 2104644 bytes.
> ==16950==
> ==16950== 28 bytes in 1 blocks are definitely lost in loss record 2 of 8
> ==16950==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
> ==16950==    by 0x8057350: (within /usr/bin/make)
> ==16950==    by 0x804B722: (within /usr/bin/make)
> ==16950==    by 0x805485A: (within /usr/bin/make)
> ==16950==
> ==16950==
> ==16950== 351 bytes in 17 blocks are definitely lost in loss record 4 of
> 8 ==16950==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
> ==16950==    by 0x1B9A88FF: strdup (in /lib/libc-2.3.2.so)
> ==16950==    by 0x8057400: (within /usr/bin/make)
> ==16950==    by 0x805B9C1: (within /usr/bin/make)
> ==16950==
> ==16950== LEAK SUMMARY:
> ==16950==    definitely lost: 379 bytes in 18 blocks.
> ==16950==    possibly lost:   0 bytes in 0 blocks.
> ==16950==    still reachable: 303379 bytes in 11006 blocks.
> ==16950==         suppressed: 200 bytes in 1 blocks.
> ==16950== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==16950== To see them, rerun with: --show-reachable=yes

I forwarded this issue to bug-make@gnu.org.

----------  Forwarded Message  ----------

Subject: Memory leak
Date: Friday 17 December 2004 16:28
From: Mark Bucciarelli
To: bug-make@gnu.org

I've been seeing garbage output to the console when running a set of tests
with make check.

I ran valgrind on make check and it indicated two memory leaks
in /usr/bin/make.

You can find all the details, including the valgrind output, here:

http://bugs.kde.org/show_bug.cgi?id=95237

When I put the tests in a bash script and run that script repeatedly, I
 got clean output every time.  make check was producing garbage every
 time.

If anyone there is a KDE hacker, you should be able to reproduce by
 running make check in kdepim/karm HEAD.

Regards,

Mark

-------------------------------------------------------

On Friday 17 December 2004 22:15, Mark Bucciarelli wrote:
> kdecvs pooh:~/build/kdepim/karm$ valgrind --leak-check=yes make check
Try adding --trace-children=yes, and removing --leak-check=yes.
Memory leaks in make are of very little importance.

I trimmed things down so my runscripts only runs one simple shell script: version.sh.

When I run this inside valgrind, I get the garbage output and the following two errors (no leaks):

==23934== Invalid read of size 1
==23934==    at 0x1BE6C24F: QProcess::normalExit() const (qprocess.cpp:420)
==23934==    by 0x804A5CA: Script::run() (script.cpp:77)
==23934==    by 0x804B688: runscripts(QString const&, QString const&, QString const&) (runscripts.cpp:89)
==23934==    by 0x804BAA0: main (runscripts.cpp:116)
==23934==  Address 0x1C942C04 is 84 bytes inside a block of size 96 free'd
==23934==    at 0x1B907616: operator delete(void*) (vg_replace_malloc.c:156)
==23934==    by 0x1BDDE89A: QProcess::~QProcess() (qprocess_unix.cpp:661)
==23934==    by 0x804A767: Script::exit() (script.cpp:96)
==23934==    by 0x804AC7C: Script::qt_invoke(int, QUObject*) (script.moc:88)
==23934==
==23934== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 67 from 1)
==23934== malloc/free: in use at exit: 3064 bytes in 66 blocks.
==23934== malloc/free: 7999 allocs, 7933 frees, 520506 bytes allocated.
==23934== For counts of detected errors, rerun with: -v
==23934== searching for pointers to 66 not-freed blocks.
==23934== checked 16617748 bytes.
==23934==
==23934== LEAK SUMMARY:
==23934==    definitely lost: 0 bytes in 0 blocks.
==23934==    possibly lost:   0 bytes in 0 blocks.
==23934==    still reachable: 2864 bytes in 65 blocks.
==23934==         suppressed: 200 bytes in 1 blocks.
==23934== Reachable blocks (those to which a pointer was found) are not shown.

I'm running qt-copy QT_3_3_3_RELEASE (revision: 1.43).

script.cpp: 77 = while ( ! m_proc->normalExit() );
script.cpp: 96 = closing brace of following method:
void Script::exit()
{
  m_status = m_proc->exitStatus();
  delete m_proc;
  m_proc = 0;
}

The entire script.cpp is here (the valgrind line #'s will not be accurate as I have some local changes):

http://webcvs.kde.org/kdepim/karm/test/script.cpp?only_with_tag=KDE_3_4_0_ALPHA_1&view=markup

I changed the test from 
 while ( !m_proc->normalExit() )
to 
 while ( m_proc->isRunning() )

and now I just get one Valgrind error:

==29655== Syscall param write(buf) contains uninitialised or unaddressable 
byte(s)
==29655==    at 0x1C4AAB38: write (in /lib/libc-2.3.2.so)
==29655==    by 0x1B9C9CDE: kdbgstream::flush() (qmemarray.h:64)
==29655==    by 0x804ADE2: Script::stderr() (kdebug.h:219)
==29655==    by 0x804B2D7: Script::qt_invoke(int, QUObject*) 
(script.moc:89)
==29655==  Address 0x52BFE3F4 is on thread 1's stack

Line 89 of script.moc (after a make clean && make check in 
build/kdepim/karm/test) is the case 1: statement in the routine below:

bool Script::qt_invoke( int _id, QUObject* _o )
{
    switch ( _id - staticMetaObject()->slotOffset() ) {
    case 0: exit(); break;
    case 1: stderr(); break;
    case 2: stdout(); break;
    case 3: terminate(); break;
    default:
        return QObject::qt_invoke( _id, _o );
    }
    return TRUE;
}

> ==29655==    by 0x1B9C9CDE: kdbgstream::flush() (qmemarray.h:64)

I commented out all kdDebug statements in script.cpp and now there are no 
Valgrind errors.

I'm not sure where the responsibility for this bug lies.

Your program writing out garbage is hardly a bug in KDirWatch :-)

#8 is clear: calling normalExit() on a QProcess instance that was already deleted (exit() called before run()).