[CLOSED] I can't debug a program that uses PasLibVLC in the IDE.

[Martin_fr]

Also, if you use gdb, you can try the option "DisableLoadSymbolsForLibraries" in the global debugger options (see the property grid on the debugger opt page)

[pcurtis]

Ok, I've tried those suggestions and still no joy. I am at a loss, what to do next?

[Martin_fr]

Ok, one step back...

1) You are indeed on Windows?
64 bit?
Intel (or AMD)  / as opposed to ARM.

Your Lazaruse is 2.0.10 or .12 ?
According to your sig Fpc 3.2.0
I am testing 3.2.2 / and have previously had 3.0.4 / never done 3.2.0

2) Lets confirm, this is about running under the debugger?
designing has no issues? (afaik PasLibVlc does not load vlc at designtime)

"Run without debugger" should also be fine?

3) More details when the problems happen?
Is the error are (dramatic) slowdown? a freeze? a crash? a ....?

Does your app - when started - immediately start playing a video?
When does the error happen? (startup, when you play/stop/seek a video?)
Does the main form show?

When using gdb, open the "Debug output" (not "console output") (either view > debug windows / or view > ide internals).
Not yet important what the output is (unless is say big and fat "error").
But how much output is made while the problem happens?
(Just to see how much gdb has to deal with)

4) Does the issue happen with the examples in PasLibVlc? (DemoPasLibVlc)
Try different videos mp4 vs avi. (more important diff codec)

Bit of background...

From what I can tell a PasLibVlc project start quite a few threads.
Depending on how often one of them terminates and/or is newly started, this can cause extra event in the debugger. That can cost a few millisecs (if loading symbols is off). Not a dramatic amount of time, but enough to change timing as perceived by vlc.
If vlc's thread sync is vulnerable to timing (pure guessing... hypothetical) then that can cause freezing.

Check in the breakpoint window, that you do not have unwanted breakpoints.

[Martin_fr]

Ok, so I tried with 2.0.12. And at least my own app freezes 99% of the time that I change a video. (while on trunk it is mostly fine / not perfect, but workable)

I haven't evaluated all of the diffs....
- Could by a change in LCL and Lazarus. But at least the IDE gdb debugger code, that is unlikely
- different gdb versions 7.3.5 for 2.0.12  / and "9.2 mod" for trunk
- different  fpdebug
- different fpc version (if vlc is loaded as lib, then even if that lib starts/stops threads that goes through fpc code)

I am not going to test all the combinations myself.

[pcurtis]

So to answer your questions -

1. Windows 10, 64 bit AMD. Laz 2.0.10, Fpc 3.2.0

2. I can design without issues. The problem occurs only when I run in the IDE.
The problem occurs with the debugger on or off (Project options >  Debugging > Generate info for debugger)

3. The app starts normally but when I try to play a movie it becomes unresponsive. The movie never plays.

4. The issue occurs also with the demo programs.

[Martin_fr]

Strange.

To complete my setup
vlc 3.0.12  just while I type this  upgraded to 3.0.14

I can play and seek  without issues.

When I try to start another video, I have maybe a 30% chance of it freezing. (maybe my code misses something...)
When I stop the current video first and wait a bit, before starting the next, its works.

That sounds much better than what you get.

It could either be the different version (Laz/Fpc/fpdebug) that I use.
Or it could be how I call the vlc lib. (though then I should have problems with the demo, and that worked for me)

It could also be the video streams in question. It could be a specific decoder...

The only thing I can think of you can try is to upgrade. I can't tell if it will help.

[MarkMLl]

When I try to start another video, I have maybe a 30% chance of it freezing. (maybe my code misses something...)
When I stop the current video first and wait a bit, before starting the next, its works.

This is not something I claim experience of, and my earlier involvement was as much as anything intended as a placeholder until you (Martin) got involved lest the OP got disgruntled and wandered off.

/BUT/... do we have a situation here where the library is using a socket to communicate with a backend, and the socket takes a bit of time to sort itself out between sessions? After all, the "L" in VLC is "LAN"...

MarkMLl

[MarkMLl]

The problem occurs with the debugger on or off (Project options >  Debugging > Generate info for debugger)

Irrelevant. What I asked earlier was whether it ran from inside the IDE without using the debugger, i.e. Run -> Run without Debugging.

Not having the debugging symbols simply means that the debugger can't do much useful, not that the debugger isn't between the OS and the program.

MarkML

[Martin_fr]

The problem occurs with the debugger on or off (Project options >  Debugging > Generate info for debugger)

Irrelevant. What I asked earlier was whether it ran from inside the IDE without using the debugger, i.e. Run -> Run without Debugging.

Not having the debugging symbols simply means that the debugger can't do much useful, not that the debugger isn't between the OS and the program.

Right, well spotted. Debug info off, is still a debugger running.  Windows still will interrupt the exe to tell the debugger about various events: exceptions, dll load/unload, threads/processes start/stop, ...

I don't suspect that any of the code is actively looking for the debugger to be present.
But I do suspect that some code may be sensitive to timing. And the debugger does change timing.
It might be a timeout on the socket. It may be thread communication. It may be something else.

[pcurtis]

OK, the code runs from inside the IDE without using the debugger.

[MarkMLl]

Are you up to trying to run the program outside the IDE under the debugger? Martin might need to fill you in on the details since he'll know where GDB is etc.

MarkMLl

[MarkMLl]

Right, well spotted. Debug info off, is still a debugger running.  Windows still will interrupt the exe to tell the debugger about various events: exceptions, dll load/unload, threads/processes start/stop, ...

And in the general case the debugger and debugee might not have the same security credentials. I've got code here which can (only) be debugged using gdbserver running as root.

MarkMLl

[pcurtis]

Why not.

GDB Is here c:\lazarus\mingw\x86_64-win64\bin\

What do I do?

[MarkMLl]

Bear in mind that I'm not running Windows, so this is general guidance only using a program to hand here. Something like

gdb something
run

I've just checked that with program using the LCL etc., and also with he main VLC binary without obvious problems although I didn't go looking for a file to play. If you need to give the debuggee parameters then it will be something like

gdb something
set args ...
run

I'm not saying it's the answer to everything, but I think it's a useful experiment. On Linux, I note various FIFOs and unix-domain sockets open, so I think there's a real possibility that this is a communications issue.

MarkMLl

[Martin_fr]

Matching gdb and gdbserver for Win64 https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/GDB%208.2/

Some sort of howto: https://wiki.lazarus.freepascal.org/Remote_Debugging#Using_gdbserver

I am logged in with an admin account. But I am not sure it's a permission issue. Too random, at least for me.

However, if my guess (timing) is right, gdbserver might still help. Gdb reports to the IDE via pipes, that takes time (especially on Win). GdbServer talks to gdb over tcp. That may or may not make a difference.