[valgrind] [Bug 328563] make track-fds support xml output

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=328563

Hideaki Kimura  changed:

   What|Removed |Added

 CC||hideaki.kim...@gmail.com

--- Comment #1 from Hideaki Kimura  ---
I'm also hitting this, but in a bit different form from the original comment
probably due to version difference (mine is 3.11.0).

When I enable track-fds and xml output, valgrind _does_ output open-at-exit
file descriptors information in XML. However, the output is far from ideal.

For example,

// test.c
#include 
int main(void) {
  open("bluh", O_CREAT, 0);
  return 0;
}

Then
gcc test.c; rm -f bluh; valgrind --xml=yes --xml-file=out.xml --track-fds=yes
--leak-check=full --error-exitcode=1 ./a.out

a.out emits no error code:
> echo $?
0

The out.xml would look like:



4
memcheck
...snip...
20082
25595
memcheck

  
/usr/bin/valgrind
--xml=yes
--xml-file=out.xml
--track-fds=yes
--leak-check=full
--error-exitcode=1
  
  
./a.out
  


  RUNNING
  00:00:00:00.056 


  FINISHED
  00:00:00:00.242 

  

  0x4F27490
  /usr/lib64/libc-2.22.so
  __open_nocancel


  0x400552
  /home/kimurhid/a.out
  main

  





This is it. The  element shows where the open-at-exit FD was made, which
is useful but the way the xml shows it is very user-unfriendly. It doesn't even
say what this  element is about!

In my case, this is also causing an issue to integrate with other tools like
Continuous Integration (Jenkins) and CTest because the output/exit-code looks
normal even when there are leaked FDs. Jenkins/CTest just report that there
were no errors.. even when I have leaked FDs!

In sum, I suggest the following:

1. In XML, make the leaked-FD output as beefy as usual memory-leak errors,
ideally follow the same format.

2. Add an option to emit error exit-code on observing leaked-FDs, again just
like usual memory-leak errors.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

--- Comment #9 from Hideaki Kimura  ---
Got it.
I didn't know how kdevelop invokes ksshaskpass, so I imagined there might be
some knob to change that behavior. But, sounds like it provides no control to
kdevelop.
I will poke the ksshaskpass people then...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

--- Comment #7 from Hideaki Kimura  ---
I wonder if  you need any more info from me?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

--- Comment #6 from Hideaki Kimura  ---
Created attachment 97602
  --> https://bugs.kde.org/attachment.cgi?id=97602=edit
password dialog

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

--- Comment #5 from Hideaki Kimura  ---
Created attachment 97601
  --> https://bugs.kde.org/attachment.cgi?id=97601=edit
username dialog

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

--- Comment #4 from Hideaki Kimura  ---
Here's the repro step.
0. If you have a global git config to automate authentication (eg per-host
private key file), turn it off. These steps are about cases you need to
manually input username/password. Also, I assume you have ksshaskpass.
1. Using git command, newly clone a git repo (either github or gitlab or
whatever) *that needs authentication*. For example, just clone a private github
reop.
2. Import the project to kdevelop, then git pull from kdevelop.
3. The first dialog asks for username, but it surely looks like asking for a
password. Type some character and Enter.
4. The second dialog asks for password. Really identical. Also, it shows the
"username" you typed above as part of URL without masking.

Also attached screenshots. You will be surprised how identical their looks are.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 347601] git username dialog looks like a password dialog

[Hideaki Kimura via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347601

Hideaki Kimura  changed:

   What|Removed |Added

 CC||hideaki.kim...@gmail.com

--- Comment #2 from Hideaki Kimura  ---
I'm not the original poster, but I have had the same concern for a while. Let
me clarify the issue.

When the kdevelop/ksshaskpass doesn't know the git username yet, it shows a
ksshaskpass dialog for username first, then another for password. Once we
configure the project to remember username, it just shows one for password.

The two dialogs look almost identical but ask for totally different things.
When the user is expecting just the password dialog, almost certainly s/he
would just type her password. This causes three issues.

1. On the screen, she would type her password without masking. Oops.

2. Furthermore, kdevelop remembers the credential! Next time it will show a
dialog that asks for password on "http://your_password_here:github.com/bluh/;
without masking. Ops.

3. Finally, there is no easy way to make kdevelop forget this setting.
Oops.
  https://forum.kde.org/viewtopic.php?f=218=129031

My suggestion is to show just one dialog in all cases (or zero dialog once the
project remembers both username and password). Make it very clear which input
box is username, which is password. Also, there should be a way to easily make
kdevelop forget the 'username'.

-- 
You are receiving this mail because:
You are watching all bug changes.