You would have to build the pdmax external from source with debug symbols to get meaningful information in the debugger. This means you would need to setup Msys2, as described in the "Windows" section in https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.

Actually, if the aim is to only get a stacktrace, it is not necessary to install a graphical frontend for GDB, you can also run GDB from the command line.

I you never compiled somthing from source it can be a bit overwhelming at first, but it's a valuable skill to have. There are a few Windows people on the list who can help you out (including myself).

So I would say it's not trivial, but also not impossible :-)

---

That's what I'm doing to debug subprocesses (I also needed to do this with [vstplugin~] a few times):

1) run Pd with DSP off and start the subprocess (here: [pd~ start()

2) find the PID of the subprocess, e.g. with "tasklist | grep <name>" or with ProcessExplorer

3) attach to the subprocess; terminal: https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb; Qt Creator: "Start Debuggin" -> "Attach to Running Application"

4) turn on DSP and wait for the subprocess to crash

If the subprocess crashes immediately even with DSP turned off, things are a bit harder.

---

If you can build pdmax with Visual Studio (I don't know if this is supported?) then things are even easier because VS has a very good built-in graphical debugger that can also attach to running applications.

Christof

On 17.11.2021 14:04, João Pais wrote:
is that something a "normal user" like me (someone that only uses the surface of the software) can do, or it has to do with C or any other custom compiled/prepared versions?

On Wed, 17 Nov 2021 at 01:06, Christof Ressi <info@christofressi.com> wrote:
You can attach GDB to a running or even a not-yet-running application.
When that application crashes, you get a backtrace. That's how I found
the crash in the [pd~] subprocess.

Personally, I use Qt Creator because it has a nice graphical front-end
for GDB where I can easily step through functions while looking at the
code, watch local variables, etc.

Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> If by any chance you're using pd 0.52 (test version) then I think
> it can crash when used as a subprocess (this should be fixed for the next
> test release).  If you're using Pd 0.51-4 the problem is something else.
>
> The "broken pipe" message means the subprocess died suddenly for some reason.
> But I can't think of an easy way to figure out what killed it.
>
> cheers
> Miller
>
> On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> Hello list,
>>
>> I have a max patch with pd inside through the pd~ object. But I'm getting
>> the "broken pipe" error in some cases in a mac, such as:
>>
>> - in a compiled standalone it usually works
>>
>> - in the original patch it doesn't
>>
>> - both patches were made in the same system, with the latest pdmax and pd
>> versions were used. I'm not sure anymore which max version or macos system
>> was used to compile the standalone, if that's important (it was either max 7
>> or 8).
>>
>> I don't have access to a mac myself, but the system where it was tested was
>> a 11.6, with Max 8. It seems to me that in some systems it works, and in
>> other it doesn't - but I don't have enough hard data to prove it.
>>
>> Best,
>>
>> Joao
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC&s=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o&e=



_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list