Bug 312200

This never happens here. Connections are every time (obviously) closed on tab closed. And the classes responsible for that destroyed. You can check in the code (TabWindow::closeTab(int) method).
What you can see is just a kio connection yet listed for some seconds after tab has been destroyed.

Am Montag, 31. Dezember 2012, 16:29:29 schrieben Sie:
> https://bugs.kde.org/show_bug.cgi?id=312200
> 
> Andrea Diamantini <adjam7@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|UNCONFIRMED                 |NEEDSINFO
>          Resolution|---                         |INVALID
> 
> --- Comment #1 from Andrea Diamantini <adjam7@gmail.com> ---
> This never happens here. Connections are every time (obviously) closed on
> tab closed. And the classes responsible for that destroyed. You can check
> in the code (TabWindow::closeTab(int) method).
> What you can see is just a kio connection yet listed for some seconds after
> tab has been destroyed.

(Happy new year Andrea!)

I know that you are right aboutTabWindow::closeTab(int). So you and everybody 
else can expect the timely closing of a network connection.
What I can state is that the timely closing you described above happens if you 
close the hole rekonq (not the tab only).

But this bug is about the tab case. I'am very sure about the reported behavior 
(here).

Now the problem starts:
I'am not aware about a (CLI) tool doing per process netstats in linux. Are 
you?
(netstat, ss, /proc don't count per PID, for using iptables -m owner I don't 
know the PID beforehand)

So I used strace and did some digging:
strace -p `pidof rekonq` -f -t -e open,write,read,close -o rekonq.trace
to catch read() and write() on fd->sockets for byte counting.
But a first look shows that this doesn't seem to match (-f!) the PID's I have 
to kill to stop the network traffic.
The PIDs to kill are shown with pstree -p as attached to kde_init->kio_http.

I did some scripting here to get a little bit automation. But before I start 
real work, I'd like to ask you if you have an idea, how to proceed?

TIA!

Bernhard

oops.. I noticed today this has been erroneously set to needsinfo -> invalid.
Correct actual bug state should be IMHO, needsinfo --> waitingforinfo.
I cannot reproduce this bug yet and I need a reproducible testcase for it.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!