https://bugs.kde.org/show_bug.cgi?id=434057
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=434057
Mark Wielaard changed:
What|Removed |Added
Status|REPORTED|ASSIGNED
Assignee|jsew...@acm.org
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #27 from Alexandra Hajkova ---
Created attachment 158030
--> https://bugs.kde.org/attachment.cgi?id=158030&action=edit
patch
this version updates:
- fix Darwin compilation
- Correct vargv arguments, last element should be NULL
- cleanup_f
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #26 from Paul Floyd ---
(In reply to Mark Wielaard from comment #24)
> (In reply to Paul Floyd from comment #21)
> Does that also mean it doesn't build on Darwin?
> We can use accept on Darwin in that case. It just means it will possibly
>
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #25 from Mark Wielaard ---
(In reply to Tom Tromey from comment #22)
> (In reply to Paul Floyd from comment #21)
>
> > I also tried to make the startup even easier and after searching a bit and
> > getting some info on SO I came up with
>
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #24 from Mark Wielaard ---
(In reply to Paul Floyd from comment #21)
> It seems quite intermittent. I've only reproduced it once, and without
> debug/verbose.
Too bad, those are the worst bugs to debug.
> I had a very quick look on Illumos
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #23 from Paul Floyd ---
To give a bit more context, the example in the xml doc is
# gdb prog
(gdb) set remote exec-file prog
(gdb) set sysroot /
(gdb) target extended-remote | vgdb --multi --vargs -q
(gdb) start
And what I was trying to to
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #22 from Tom Tromey ---
(In reply to Paul Floyd from comment #21)
> I also tried to make the startup even easier and after searching a bit and
> getting some info on SO I came up with
I don't know the exact problem here -- I don't use "ext
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #21 from Paul Floyd ---
It seems quite intermittent. I've only reproduced it once, and without
debug/verbose.
I had a very quick look on Illumos and Darwin and Illumos has a man page for
accept4 but not Darwin.
I also tried to make the sta
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #20 from Mark Wielaard ---
I wonder if there is still a timing issue if it works with extra verbose/debug
output. We tried to remove any explicit waiting/spinning.
Could you show a full session (gdb command line plus arguments and gdb promp
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #19 from Paul Floyd ---
I tried again (with lots of -d / -v) and it worked.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #18 from Paul Floyd ---
Builds cleanly on FreeBSD
But I still get errors like
(gdb) start
Temporary breakpoint 4 at 0x201ab8: file new_delete_mismatch_size.cpp, line 12.
Starting program:
/usr/home/paulf/scratch/valgrind/memcheck/tests/new
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #17 from Paul Floyd ---
I'll have a go over the weekend.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #16 from Mark Wielaard ---
Thanks, last patch looks pretty nice.
I threw it at the try builder and it at least compiles cleanly:
https://builder.sourceware.org/buildbot/#/changes/23263
That of course is all different GNU/Linux setups, maybe
https://bugs.kde.org/show_bug.cgi?id=434057
Alexandra Hajkova changed:
What|Removed |Added
Attachment #157862|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=434057
Alexandra Hajkova changed:
What|Removed |Added
Attachment #157529|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #13 from Paul Floyd ---
> I see accept4 (which is used to set SOCK_CLOEXEC) is also a GNU extension.
> But that does also work on other systems?
It compiles and there is a manpage for accept4 which is always a good start.
I thought the ne
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #12 from Mark Wielaard ---
(In reply to Paul Floyd from comment #11)
> When I saw this
>
> +/* For accept4 and execvpe. */
> +#define _GNU_SOURCE
> #include "vgdb.h"
>
> I had a bit of a bad feeling, which was confirmed when I tried to b
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #11 from Paul Floyd ---
When I saw this
+/* For accept4 and execvpe. */
+#define _GNU_SOURCE
#include "vgdb.h"
I had a bit of a bad feeling, which was confirmed when I tried to build.
vgdb.c:1185:16: warning: implicit declaration of fun
https://bugs.kde.org/show_bug.cgi?id=434057
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=434057
Alexandra Hajkova changed:
What|Removed |Added
Attachment #153923|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=434057
Sam James changed:
What|Removed |Added
CC||s...@gentoo.org
--
You are receiving this mail bec
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #9 from Alexandra Hajkova ---
Created attachment 156128
--> https://bugs.kde.org/attachment.cgi?id=156128&action=edit
patch
The new updated version
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #8 from Mark Wielaard ---
We reviewed (about half) of the patch and found a couple of things to cleanup:
- There is a sleep(3) after fork, before execve in the parent (vgdb) to wait
for valgrind to fully startup
This should be replaced wi
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #7 from Alexandra Hajkova ---
Created attachment 153923
--> https://bugs.kde.org/attachment.cgi?id=153923&action=edit
patch
vgdb: Add multi mode
In this mode, Vgdb uses extended remote protocol to communicate with Gdb.
in the ext
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #6 from Mark Wielaard ---
There is a fork on sourcehut that contains the start of work on a --multi
option for vgdb that implements extended-remote mode so that vgdb can start a
valgrind process in response to a vrun packet. Currently the vg
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #5 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #4)
> This is only half of the work though. Although you can change the way gdb
> and vgdb communicate (it doesn't need to be through stdio, but we could also
> add a "normal"
https://bugs.kde.org/show_bug.cgi?id=434057
--- Comment #4 from Mark Wielaard ---
We have been looking at this and for the valgrind side it would involve
something like Pedro suggests in comment #3. So vgdb would intercept the
extended-remote packages (which aren't currently implemented in the va
https://bugs.kde.org/show_bug.cgi?id=434057
Mark Wielaard changed:
What|Removed |Added
CC||ahajk...@redhat.com
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=434057
Pedro Alves changed:
What|Removed |Added
CC||pe...@palves.net
--- Comment #3 from Pedro Alves
https://bugs.kde.org/show_bug.cgi?id=434057
Mark Wielaard changed:
What|Removed |Added
CC||m...@klomp.org
--- Comment #2 from Mark Wielaar
https://bugs.kde.org/show_bug.cgi?id=434057
Philippe Waroquiers changed:
What|Removed |Added
CC||philippe.waroquiers@skynet.
32 matches
Mail list logo
