hi all
i encountered a very strange bug, that seems to be very difficult to
trace back. although i cannot provide very usuable information at this
point (i assume), i just wanted to report it anyway. as i am not a coder
and also not experienced in debugging, some of you might have hints and
ideas how to proceed.
i can reliably crash pd, but only if a fulfill a rather funny set of
conditions. creating a [table yoyo 6e+07] pd crashes, but only:
-if i first loaded _chat.pd from netpd
-if pd is running over jack
it doesn't crash, when pd is not connected to jack while instantiating
the table. it also doesn't crash, when i first instantiate the [table]
and then load _chat.pd.
i found out, that it might be related to an external, that _chat.pd is
using. loading _chat.pd without the externals makes the bug
untriggerable. i haven't shrinked it down to one specific external, but
i will do so as soon as i find time. here is the list of externals, that
_chat.pd is using (only from zexy and maxlib):
netclient v0.3, written by Olaf Matthes <olaf.matthes(a)gmx.de>
[makesymbol] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[list2symbol] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[any2list] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[symbol2list] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[drip] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[lister] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[glue] part of zexy-2.2.0 (compiled: Dec 7 2007)
Copyright (l) 1999-2007 IOhannes m zm�nig, forum::f�::uml�te &
IEM
[table yoyo 6+07] is here only used to make pd reserve a certain amount
of memory. the same happens with a number of tables, that uses the same
amount of memory. it can also be triggered by loading heavy patches,
that cause pd to use the exact same amount of memory. the limit seems to
be somewhere around 228MB.
i tested it on two computers:
pd-0.40.3 / ubuntu dapper / pentium M / 512MB RAM
pd-0.40.3 / ubuntu gutsy / amd (can't recall exact model) / 1.5GB RAM
and on both i encountered the exact same behaviour. however, someone
from #dataflow tried to trigger it as well and failed. actually i don't
even know, if it is worth investigating it, since i found a way to use
more memory with pd than 228MB.
comments appreciated.
roman
here the output of:
valgrind pd -rt -stderr -jack -channels 6 -open /home/roman/netpd/_chat.pd
(after instantiating [table yoyo 6e+07]), if this could be of any help:
pd: resizebytes() failed -- out of memory
==11536==
==11536== Thread 1:
==11536== Invalid write of size 4
==11536== at 0x8078C74: word_init (g_scalar.c:27)
==11536== Address 0x4 is not stack'd, malloc'd or (recently) free'd
==11536==
==11536== Process terminating with default action of signal 11 (SIGSEGV)
==11536== Access not within mapped region at address 0x4
==11536== at 0x8078C74: word_init (g_scalar.c:27)
==11536==
==11536== ERROR SUMMARY: 150 errors from 27 contexts (suppressed: 23
from 1)
==11536== malloc/free: in use at exit: 332,958 bytes in 11,950 blocks.
==11536== malloc/free: 19,862 allocs, 7,912 frees, 242,700,919 bytes
allocated.
==11536== For counts of detected errors, rerun with: -v
==11536== searching for pointers to 11,950 not-freed blocks.
==11536== checked 18,409,376 bytes.
==11536==
==11536== LEAK SUMMARY:
==11536== definitely lost: 4,149 bytes in 59 blocks.
==11536== possibly lost: 136 bytes in 2 blocks.
==11536== still reachable: 328,673 bytes in 11,889 blocks.
==11536== suppressed: 0 bytes in 0 blocks.
==11536== Use --leak-check=full to see details of leaked memory.
Killed
pd_gui: pd process exited
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hi,
I fail to cross-compile pdlua on Debian for W32. This is my error:
$ i586-mingw32msvc-gcc -I/lua-5.1.2/src/ -I./ -I/usr/include/ -shared lua5.1.dll pd.dll -o lua.dll lua.c
/tmp/ccobudhL.o:lua.c:(.text+0x1bc4): undefined reference to `_class_set_extern_dir'
/tmp/ccobudhL.o:lua.c:(.text+0x1c65): undefined reference to `_class_set_extern_dir'
/tmp/ccobudhL.o:lua.c:(.text+0x1c92): undefined reference to `_class_set_extern_dir'
/tmp/ccobudhL.o:lua.c:(.text+0x1e09): undefined reference to `_sys_register_loader'
Info: resolving _s_ by linking to __imp__s_ (auto-import)
collect2: ld returned 1 exit status
This is with the precompiled lua5.1.dll from
http://luabinaries.luaforge.net/download.html and the precompiled
pd.dll from Miller's site, both 0.41 and 0.40 give the same error.
I could remove the "_class_set_extern_dir" stuff from lua.c, but I'm
quite sure that "_sys_register_loader" is important.
Any ideas how to fix this?
Ciao
--
Frank Barknecht _ ______footils.org__
Patches item #1848356, was opened at 2007-12-10 21:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848356&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: Yes
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: streamin/streamout doc updates, bugs, and a security issue
Initial Comment:
This issue has been marked private as it includes details on a remotely exploitable buffer overflow vulnerability in the code for [streamin~].
A while ago, I was looking around at different options for streaming audio in and out of Pd. I spent a short time looking at the code for [streamin~] and [streamout~]. I ended up not using them for my project. However, I made this set of changes while looking at the code.
Since I moved on to something else, these changes aren't exactly complete, but point out some important things, so I think they may be worth putting in as is.
Here is a summary of the changes that are included.
stream.h changes:
1) doxygen style documentation updates
2) added an ifdef to protect against multiple or recursive inclusion of the header
3) Documentation of some of the fields in the data structures
4) Fixed potential alignment bugs by adding the packed attribute for the structure that defines frame headers. This attribute should always be used when it is used to directly interpret data from the network or when used to prepare data to send directly over the network. This section of the gcc manual has a tidbit about the attribute:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Variable-Attributes.html#Variab…
5) Point out the fact that the code is not endianness-safe. The code should eventually be updated to respect network byte order.
6) Point out that the version field of the frame header is ignored when parsing incoming frames. It should eventually be checked, but doesn't matter much until the format gets changed such that the version number gets bumped.
7) Change a list of #defines to an enum, for the sake of better coding practice.
8) Change the use of "int" in the frame header structure to explicitly list that the field is 32-bits by using the int32_t type.
streamin~.c changes:
1) Fix a remotely exploitable buffer overflow that would allow remote execution of arbitrary code. The frame header includes 4 bytes to specify the frame length. However, the code only allocates enough space for the frame header and 256 bytes of payload data. The size portion of the frame header was not checked to ensure that its value was valid. This little hack should fix it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848356&group_…
Patches item #1848295, was opened at 2007-12-10 18:53
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix small potential stack overflow
Initial Comment:
Attached is a patch to fix another potential stack buffer overflow in s_main.c. I didn't send this over in private because I don't think it can be exploited in any useful way, so it's just a small bug.
----------------------------------------------------------------------
>Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:41
Message:
Logged In: YES
user_id=1942915
Originator: YES
Also, let me just clarify my original summary just a little bit.
You can cause the overrun of the buffer by providing a really long input
string to the -schedlib command line option. It's just not exploitable in
such a way that it would be considered a security issue.
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:38
Message:
Logged In: YES
user_id=1942915
Originator: YES
I'm sorry for the stupid typo. That code is actually only compiled in for
a Windows build (whenever MSW is defined), so I didn't notice.
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:36
Message:
Logged In: YES
user_id=1942915
Originator: YES
File Added: filename_overflow.patch2.txt
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-12-10 19:18
Message:
Logged In: YES
user_id=27104
Originator: NO
I am guessing there is a typo in that patch, since the new line also uses
sprintf() instead of snprintf():
- sprintf(filename, "%s.dll", sys_externalschedlibname);
+ sprintf(filename, sizeof(filename), "%s.dll",
sys_externalschedlibname);
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Patches item #1848295, was opened at 2007-12-10 18:53
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix small potential stack overflow
Initial Comment:
Attached is a patch to fix another potential stack buffer overflow in s_main.c. I didn't send this over in private because I don't think it can be exploited in any useful way, so it's just a small bug.
----------------------------------------------------------------------
>Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:38
Message:
Logged In: YES
user_id=1942915
Originator: YES
I'm sorry for the stupid typo. That code is actually only compiled in for
a Windows build (whenever MSW is defined), so I didn't notice.
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:36
Message:
Logged In: YES
user_id=1942915
Originator: YES
File Added: filename_overflow.patch2.txt
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-12-10 19:18
Message:
Logged In: YES
user_id=27104
Originator: NO
I am guessing there is a typo in that patch, since the new line also uses
sprintf() instead of snprintf():
- sprintf(filename, "%s.dll", sys_externalschedlibname);
+ sprintf(filename, sizeof(filename), "%s.dll",
sys_externalschedlibname);
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Patches item #1848295, was opened at 2007-12-10 18:53
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix small potential stack overflow
Initial Comment:
Attached is a patch to fix another potential stack buffer overflow in s_main.c. I didn't send this over in private because I don't think it can be exploited in any useful way, so it's just a small bug.
----------------------------------------------------------------------
>Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 20:36
Message:
Logged In: YES
user_id=1942915
Originator: YES
File Added: filename_overflow.patch2.txt
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-12-10 19:18
Message:
Logged In: YES
user_id=27104
Originator: NO
I am guessing there is a typo in that patch, since the new line also uses
sprintf() instead of snprintf():
- sprintf(filename, "%s.dll", sys_externalschedlibname);
+ sprintf(filename, sizeof(filename), "%s.dll",
sys_externalschedlibname);
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Patches item #1848295, was opened at 2007-12-10 19:53
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix small potential stack overflow
Initial Comment:
Attached is a patch to fix another potential stack buffer overflow in s_main.c. I didn't send this over in private because I don't think it can be exploited in any useful way, so it's just a small bug.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-12-10 20:18
Message:
Logged In: YES
user_id=27104
Originator: NO
I am guessing there is a typo in that patch, since the new line also uses
sprintf() instead of snprintf():
- sprintf(filename, "%s.dll", sys_externalschedlibname);
+ sprintf(filename, sizeof(filename), "%s.dll",
sys_externalschedlibname);
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Patches item #1848292, was opened at 2007-12-10 19:49
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848292&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ggee/makefile.sub cleanup and documentation
Initial Comment:
I went looking around through externals. Specifically, I was interested in looking at [streamin~]/[streamout~]. I was also interested in how the externals were being built.
So, while looking at how these externals were built, I made some significant changes to this Makefile.
Changes:
ggee/signal/Makefile:
- Simply add the -f option to rm to avoid errors being sent to the console when files don't exist to get removed.
ggee/makefile.sub:
- Added comments to sections of the Makefile to describe what they are for
- Centralized the handling of CFLAGS and LDFLAGS to one spot so it is clear what is platform specific.
- Re-work the compilation and linking targets so that they use the new handling of the CFLAGS and LDFLAGS.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-12-10 20:16
Message:
Logged In: YES
user_id=27104
Originator: NO
hehe, no prob
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 19:51
Message:
Logged In: YES
user_id=1942915
Originator: NO
Please delete this issue ...
I hit refresh on a really old browser window and it re-POSTed this. Oops!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848292&group_…
Patches item #1848295, was opened at 2007-12-10 18:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix small potential stack overflow
Initial Comment:
Attached is a patch to fix another potential stack buffer overflow in s_main.c. I didn't send this over in private because I don't think it can be exploited in any useful way, so it's just a small bug.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848295&group_…
Patches item #1848292, was opened at 2007-12-10 18:49
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848292&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ggee/makefile.sub cleanup and documentation
Initial Comment:
I went looking around through externals. Specifically, I was interested in looking at [streamin~]/[streamout~]. I was also interested in how the externals were being built.
So, while looking at how these externals were built, I made some significant changes to this Makefile.
Changes:
ggee/signal/Makefile:
- Simply add the -f option to rm to avoid errors being sent to the console when files don't exist to get removed.
ggee/makefile.sub:
- Added comments to sections of the Makefile to describe what they are for
- Centralized the handling of CFLAGS and LDFLAGS to one spot so it is clear what is platform specific.
- Re-work the compilation and linking targets so that they use the new handling of the CFLAGS and LDFLAGS.
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-10 18:51
Message:
Logged In: YES
user_id=1942915
Originator: NO
Please delete this issue ...
I hit refresh on a really old browser window and it re-POSTed this. Oops!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848292&group_…