bugGNU Octave - Bugs: bug #37672, GUI doesn't react to CTRL+C

 
 

bug #37672: GUI doesn't react to CTRL+C

Submitted by:  Thorsten Liebig <thorsten>
Submitted on:  Tue 06 Nov 2012 09:03:06 AM UTC  
 
Category: GUISeverity: 4 - Important
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 03 Aug 2014 08:37:42 AM UTC, comment #54:

I have copied this comment on the behavior of Ctrl-C on windows (3.8.1) from bug #42867 by Nirmal:

Run the following script. Then press control-C twice when it pauses. We get prompt. Press Control-C again to abort.
Now press control-c again, to see program crash.

Torsten <ttl>
Project Member
Fri 24 Jan 2014 08:19:13 PM UTC, comment #53:

Marking as not a regression bug now. It was when Ctrl-C had been broken in CLI mode temporarily but was fixed well before the 3.8 release.

Mike Miller <mtmiller>
Project Member
Tue 10 Dec 2013 10:57:32 AM UTC, comment #52:

I wanted to give a short update on this bug:

Linux (Kubuntu 13.04) with latest default tip (ec9b35e60f95):
No GUI: interrupting a system command works as it should.... (good)
GUI: interruption does not work (BAD!)

Windows using the latest mxe-octave (730fe4ac1a29):
No-GUI + GUI: It works in both cases (very good)

So to summarize:
Only Linux + GUI (the only combination I personally care about) does still not work at all... :(

Thorsten Liebig <thorsten>
Mon 25 Nov 2013 09:38:26 PM UTC, comment #51:

I'm attaching a change that allows system() to be interrupted when running Octave with the GUI on Unixy systems. However, I don't think we can use this change because it will make Octave crash when interrupting calls to multi-threaded BLAS functions, for example.

The only other thing I can think of is to somehow get (or track) the list of processes that are in the same process group as Octave and send SIGINT to all of them except the Octave process and then use pthread_kill to send SIGINT to the Octave interpreter thread. Is there some easy way to get the list of processes in the process group? If not, then it will take some work to keep track of the processes that we create, and it won't be possible to track all of the processes that might be created in .oct files (for example).

(file #29713)

John W. Eaton <jwe>
Project Administrator
Thu 21 Nov 2013 10:32:58 PM UTC, comment #50:

John,

If I interpret you correctly you are proposing
to start the release candidate process with the
system as it is now.

This definitely seems appropriate to me.

It is pretty likely that there will be sufficient
issues with RC1 to allow time for the items that
you listed to be resolved (if they have a viable
solution at all).

Michael Godfrey <godfrey>
Thu 21 Nov 2013 10:22:23 PM UTC, comment #49:

At this point, I think we are down to the following problems:

1. Interrupting readline input doesn't work when running the command-line version of Octave on Windows.

2. Interrupting system() doesn't work when running the GUI version of Octave on Unixy systems.

I'd really like to see both of these problems fixed before the release, but they don't necessarily have to be fixed before we make the first release candidate.

John W. Eaton <jwe>
Project Administrator
Mon 18 Nov 2013 06:06:34 PM UTC, comment #48:

This should have high priority, but if it
is still outstanding when other blockers are
cleared I would prefer that it NOT block the
release.

Michael Godfrey <godfrey>
Mon 18 Nov 2013 05:50:01 PM UTC, comment #47:

The current situation is that long-running Octave functions can be interrupted in the CLI, --no-gui, and GUI versions of Octave.

Example Code 1 : Internal function

For commands outside of Octave, the function can be interrupted in the CLI and --no-gui versions, but not in the GUI.

Example Code 2 : External function

This is still listed as a blocker on the 3.8. Bug Fix list. Do we still consider that to be the case, or is this fixed enough for the release?

Rik <rik5>
Project Administrator
Fri 15 Nov 2013 03:34:08 AM UTC, comment #46:

It's unclear to me what has been fixed and should work now, I haven't been following too closely.

Built tonight, I can interrupt long-running Octave functions, but interrupts do not seem to be sent on to child processes invoked from Octave, e.g. through system(). Is this expected or should be working now?

Doing either system("sleep 30") or system("watch ls") in the GUI results in something that can't be interrupted at all.

Also making "less" come up and then pressing "F" to enter tail mode results in something that can't be interrupted (this was reported in another bug that I marked as a duplicate of this one).

Mike Miller <mtmiller>
Project Member
Thu 14 Nov 2013 07:48:36 PM UTC, comment #45:

I'm NOT running on Windows of course ;)

I use Kubuntu 13.10 and 13.04 on another machine and it is not working for me. Strange...
Am I the only one??

I'm just occasionally building and testing the mxe-version for Windows...

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 07:41:32 PM UTC, comment #44:

Thorsten: Are you running on Windows?

Yes, it used to work but Ctrl-C as copy did not work. Apparently, people want both of these things to work.

It does work for me now on my Debian system. So I think the problem is fixed for Unixy systems with pthreads.

I don't expect it to work properly on Windows systems yet.

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 07:31:40 PM UTC, comment #43:

jwe: I was using 345a8027dc8b with a fresh build folder.

But I have just now tried again with a fresh hg clone (now 97bde75d4119)
What was the command for a clean clone? hg purge ?

fresh clone
./bootstrap
mkdir / cd .build
../configure
make -j3
./run-octave

and I am still unable to interrupt a system('sleep 10') or anything similar.

with ./run-octave --no-gui everything works fine...

So no improvement for me :(

And I might again point out my first comment, that with Octave 3.7.5 with mxe on Windows, CTRL+C worked like it should, but stopped at some point and started behaving like on Linux...

regards
Thorsten

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 04:31:59 PM UTC, comment #42:

Thorsten: I think it should work.

How did you build? Rik mentioned that he had trouble until he built from scratch. I don't know whether that is really needed, but maybe there was some problem with the build for you that causes trouble.

What is your hg id?

How are you running Octave?

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 04:02:35 PM UTC, comment #41:

jwe: changes from the latest commits you made. I thought Rik meant that CTRL+C now works within the GUI...
But the current tip does not show any change in behavior for me (Kubuntu 13.04)

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 04:01:04 PM UTC, comment #40:

Just run octave-cli seems better to me.
The command-line option seems potentially
confusing, and there are a lot of those already.

Michael Godfrey <godfrey>
Thu 14 Nov 2013 03:54:27 PM UTC, comment #39:

Maybe we should document --no-gui-libs. Or you can just run octave-cli directly.

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 03:53:41 PM UTC, comment #38:

Thorsten: Change from what?

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 03:52:44 PM UTC, comment #37:

--no-gui works fine as ever, but I don't see any change with the GUI? Am I supposed to?

Thorsten Liebig <thorsten>
Thu 14 Nov 2013 03:48:31 PM UTC, comment #36:

--no-gui
and ctrl-c works for me, too. Very good.

Since --no-gui-libs is not documented is it
intended for some "internal" purpose?

Michael Godfrey <godfrey>
Thu 14 Nov 2013 03:35:57 PM UTC, comment #35:

All three ways of invoking Octave now work with

Rik <rik5>
Project Administrator
Thu 14 Nov 2013 03:14:13 PM UTC, comment #34:

Maybe we won't have to make --no-gui mean --no-gui-libs. I checked in the following change:

http://hg.savannah.gnu.org/hgweb/octave/rev/345a8027dc8b

This seems to fix the problem for me with signal handling and the --no-gui option. It should work on systems that use pthreads. It won't do anything for us on Windows systems. I'll post something on the maintainers list about signal handling and Windows.

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 01:16:35 PM UTC, comment #33:

Good. For the 3.8 release making --no-gui mean --no-gui-libs
seems fine. Getting Qt GUI elements to work can be done
later. Just having GUI or --no-gui is better than three flavors
anyhow. And, there is enough work on blockers already.

So, I am for making --no-gui mean --no-gui-libs. If it is
needed for testing Qt in no-gui mode some other temporary
mechanism can be used.

Michael Godfrey <godfrey>
Thu 14 Nov 2013 06:25:46 AM UTC, comment #32:

I mean that Qt GUI elements will not work from the command line interface. FLTK plotting will still work. But we would like to use Qt widgets for plotting and UI elements, and I think that should work from the command line. Michael Goffioul had that working with QtHandles, though I'm not sure what the status of interrupt handling was with his wrapper program that set up the Qt application context.

John W. Eaton <jwe>
Project Administrator
Thu 14 Nov 2013 06:21:09 AM UTC, comment #31:

John,

I think that for now the change that you propose
of making --no-gui mean --no-gui-libs is OK.

But, what do you mean by "graphics may not work"?
If this change breaks the standard usage of fltk
and gnuplot, then I think that has to be fixed.

I just tried a number of plots using fltk and saw
no problems.

Michael Godfrey <godfrey>
Thu 14 Nov 2013 06:03:20 AM UTC, comment #30:

The idea is for --no-gui-libs to bring up a command-line only version of Octave in which graphics and any graphical user interface elements might not even work. The --no-gui option should start Octave in a command-line mode that still allows graphics and ui* functions to work. But currently the --no-gui thing is not really working, so I'm beginning to think that we should just make --no-gui mean the same as --no-gui-libs for the 3.8 release. Then interrupt handling is solved for those two cases. It also looks like the pthread_kill/pthread_sigmask thing works for the GUI in Unix systems. Then we are just left with making interrupts work properly for Windows systems.

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 11:31:08 PM UTC, comment #29:

OK. That is it.

I have been running, due to .octaverc, in
effect octave --no-gui

If I run octave --no-gui-libs
ctrl-c works.

What is octave --no-gui for these days?

Is --no-gui-libs the right way to get --no-gui?

Michael Godfrey <godfrey>
Wed 13 Nov 2013 11:25:02 PM UTC, comment #28:

I think there has been a regression, although I'll have to go back and re-compile to make sure. Here are my results on the most recent tip:

run-octave -f : works (in GUI)
run-octave -f --no-gui-libs : works (in raw CLI)
run-octave -f --no-gui : BAD

Maybe the problem is that when running --no-gui the CopyClipboard function is not available since the GUI isn't running.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 11:08:35 PM UTC, comment #27:

Rik,

Did your system respond to ctrl-c after full cleaning?

Michael Godfrey <godfrey>
Wed 13 Nov 2013 11:02:55 PM UTC, comment #26:

I tried:

kill -INT 5875

no effect
kill -9 5875
killed octave (just proves I had the PID right.)

Michael Godfrey <godfrey>
Wed 13 Nov 2013 10:51:50 PM UTC, comment #25:

Michael,

I also had the same problem where Ctrl+C was not recognized after just doing "hg pull; hg update; make". In the end, 'make clean' and 'make distclean' were not enough. I had to run 'make maintainer-clean' and then also delete libgui/src/src_libgui_src_la-octave-main-thread.lo. Then I re-ran the bootstrap, configure, and make cycle.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 10:01:16 PM UTC, comment #24:

Michael Godfrey:

What about the test with "kill -INT PID":

What happens if you execute "sleep (200)" at the Octave prompt and then do "kill -INT PID" with PID == the process ID of the Octave process? This should be the one that is shown as "octave" in the output from ps, not the "lt-octave-gui" process.

Does that deliver an interrupt signal to Octave? If so, does it interrupt the sleep function?

I'm trying to determine whether it is a problem with Ctrl-C not being acted on by Qt (we expect that it is defined as a keyboard shortcut that will eventually put us in the copyClipboard function in the terminal widget) or if it is that signal handling is not working.

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 08:29:26 PM UTC, comment #23:

I just did a complete rebuild and get
the same results as below. No sign of the
ctrl-c being seen at all.

Michael Godfrey <godfrey>
Wed 13 Nov 2013 06:14:20 PM UTC, comment #22:

On Windows, interrupting a loop like "more off; for i = 1:100000, i, end" should work, but interrupting an external library function like "inv (large_matrix)" probably won't work becuase the setjmp/longjmp thing fails.

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 06:03:01 PM UTC, comment #21:

I did a full maintainer-clean, followed by bootstrap, configure, make to get rid of any cruft. After getting past the missing config.h include in octave-dock-widget.cc, I now have Ctrl+C working on a Mint (Debian-derivative) system. I will try and cross-compile for MinGW and see how it works over there.

Rik <rik5>
Project Administrator
Wed 13 Nov 2013 06:02:11 PM UTC, comment #20:

Sorry, I meant:

Also, what happens if you select some text in the command window and type Ctrl-C? Does it copy the selected text to the clipboard so that Ctrl-V copies it to the command prompt?

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 05:59:34 PM UTC, comment #19:

What happens if you execute "sleep (200)" at the Octave prompt and then do "kill -INT PID" with PID == the process ID of the Octave process? This should be the one that is shown as "octave" in the output from ps, not the "lt-octave-gui" process.

Also, what happens if you select some text in the command window and type Ctrl-C? Does it paste the selected text?

Does Ctrl-C give you a new prompt when Octave is otherwise idle and waiting for input?

Does Ctrl-C interrupt loops like "more off; for i = 1:1000000; i, end"?

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 04:47:13 PM UTC, comment #18:

Michael, what happens if you type Ctrl-C when inv is working on a large matrix? For example

Pause for a half second or so before interrupting the inv command because there is a call to std::copy at the top of that function that must complete before you get to the code that will react to SIGINT by doing a longjmp. If you type Ctrl-C twice while the std::copy is working, you'll get a message about typing Ctrl-C again to abort Octave. If you do that before reaching the code where Octave uses setjmp/longjmp, you'll exit Octave.

What about if you go back to the changeset prior to my latest patches? Try "hg up -C c9f622fd7307", then build again and try the test above. I expect that Octave will exit when you type Ctrl-C, and that will happen without the message about typing Ctrl-C again to abort. So without the patches, interrupting doesn't work properly. With them, I'm hoping that it is just sleep that is affected.

John W. Eaton <jwe>
Project Administrator
Wed 13 Nov 2013 04:00:22 PM UTC, comment #17:

I just tried the latest fixes from John.
But, for Fedora 19, they seem not to work.
Now, running sleep(2) in any form results
in ctrl-c not being handled at all.

I tried:
octave:3> system("sleep 20")
^C^C^Cans = 0
octave:4> sleep(2)
^Coctave:5> sleep(20)
^C^C^C^Coctave:6>
octave:6> system("sleep 20")
^C^C^C^Cans = 0
octave:7>
=============================
Before, 2 ctrl-c's worked. So, this fix
is a regression. Getting interrupts to work
right is one of serious problems in today's
popular systems.

But, for Fedora linux at least, reverting this
latest set of patches would be better.

Michael Godfrey <godfrey>
Thu 17 Oct 2013 09:41:41 PM UTC, comment #16:

I can confirm that problems with handling Ctrl-C while the interpreter is sleeping is not limited to Windows. I looked at it but could not find a quick fix.

John W. Eaton <jwe>
Project Administrator
Thu 03 Oct 2013 04:12:26 PM UTC, comment #15:

(In response to Mike's request at bug #40156)

In 3.7.6+ GUI (MXE-cross-built, on WinXP), trying to interrupt 'system ("sleep 50")' doesn't work. I get after Ctrl-C twice separated three secs apart:

...and the next (3rd) Ctrl-C kills Octave with an error about
"The instruction at '0x67777e70' referencing memory at '0x00000000'. The memory could not be read
Click OK to terminate the program"

I tend to suspect this is due to Octave calling an external program; either Octave doesn't correctly transfer the interrupt to sleep(), or sleep() itself doesn't want to be interrupted (improbable I think), or Octave doesn't correctly pick up sleep()'s return. I'd go for the first because sleep() goes on and on.... it apparently never gets the signal.

However... in 3.7.6+ CLI, interrupting 'system ("sleep 50")' gives (after Ctrl-C within 3 secs):

and promptly returns to the prompt (no pun intended) after Ctrl-C so in the CLI it works OK (I can only vouch for my own box, of course).
FYI, on 3.6.4 the return value is 0 rather than 258.

Internal stuff (i.e., scripts, Octave commands) CAN be interrupted - already in Octave-3.6.4. I never noted a regression. I've been busy lately with processing (big) spreadsheets; time-consuming stuff like complicated regexps on MB size strings can be aborted, w/o effects for stability etc.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 28 Jul 2013 07:38:47 PM UTC, comment #14:

Setting status back to confirmed since we have a couple of cases here that are not responding to user interrupt correctly.

Here's another one:

In the command line, any child process receives the SIGINT, in this case the command exits immediately and the exit status is non-zero.

Same with the 'F' command in the less pager, which runs to the end of the input and waits for a user interrupt. If it cannot be interrupted, it never returns and Octave has to be killed. See bug #37468 (assigning as a duplicate of this bug now).

In the GUI both of these examples just hang, the child process does not receive the SIGINT.

Mike Miller <mtmiller>
Project Member
Wed 17 Jul 2013 06:33:14 PM UTC, comment #13:

With a fresh build, the cli version aborts correctly on my system, too.

Torsten <ttl>
Project Member
Tue 16 Jul 2013 08:17:45 AM UTC, comment #12:

The same for me, runs and aborts clean as expected in cli-mode and crashes in GUI mode...
To me the command line interface looks all good...

Thorsten Liebig <thorsten>
Tue 16 Jul 2013 05:08:46 AM UTC, comment #11:

It does not crash for me in command-line mode, it just breaks out of the loop immediately as it should:

Mike Miller <mtmiller>
Project Member
Mon 15 Jul 2013 08:30:15 PM UTC, comment #10:

Also the cli version of crashes when trying to abort Thorsten's second example with ctrl-c. This does not seem to be a gui problem. The error message is:

+verbatim*
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
-verbatim-

Torsten <ttl>
Project Member
Mon 15 Jul 2013 05:41:52 PM UTC, comment #9:

Even the mxe build on windows does not abort a sleep () or Thorsten's second example with Ctrl-C (or with Ctrl-Shift-C) before the patch).

Torsten <ttl>
Project Member
Mon 15 Jul 2013 07:46:07 AM UTC, comment #8:

Well in my case it does not even exit, I have to kill (SIGKILL) the frozen GUI manually...

Thorsten Liebig <thorsten>
Sun 14 Jul 2013 11:36:31 PM UTC, comment #7:

Confirmed Thorsten's second example here, running the GUI in gnome shell. The GUI exits immediately as soon as ctrl-c is pressed while in the computational loop.

Mike Miller <mtmiller>
Project Member
Sun 14 Jul 2013 11:55:44 AM UTC, comment #6:

What do you mean by normal script?

I tried this (as a script):

If I hit CTRL+C it aborts after the next sleep is done. It seems that the GUI (on Linux) is unable to interrupt a command and can only stop the script after a sleep is done??

I tried something more useful than sleep:

trying to abort this with CTRL+C, ends up in a complete hangup/freeze and crash of Octave :(

Something here is pretty broken, at least for me...

Thorsten Liebig <thorsten>
Sun 14 Jul 2013 11:34:35 AM UTC, comment #5:

I can conform the effect that sleep can not be aborted and will have a look at it.

Thorsten, are normal octave-scripts interrupted by ctrl-c on kubuntu?

Torsten <ttl>
Project Member
Sat 13 Jul 2013 10:21:27 PM UTC, comment #4:

I do see that ctrl-c does cancel the current line being edited if no text is selected. It also does break out of a long-running for loop. But I don't see the following working in the GUI, which works fine in terminal mode:

first ctrl-c: nothing happens
second ctrl-c: "Press Control-C again to abort."
third ctrl-c: Octave exits

So the interrupt is being caught by sigint_handler, but does not break the sleep function.

Mike Miller <mtmiller>
Project Member
Sat 13 Jul 2013 06:32:01 PM UTC, comment #3:

I do NOT see any change on my Kubuntu!

I'm still unable to abort my scripts using crtl+c

Maybe it is important to add some more details:

I'm running an external binary for my numerical simulations using the octave "unix" command and it is this process the Octave-GUI can't interrupt.
As a matter of fact, I can't exit the GUI at all. The close button or File->Exit do not react as well. Not even a normal process kill (SIGTERM) does it.
After the unix command finishes the GUI crashes.. but only if I tried to abort it with CTRL+C

With the "no-gui", octave reacts as expected and as I mentioned so does the GUI and no-gui version for Windows (mxe build).

regards
Thorsten

Thorsten Liebig <thorsten>
Thu 11 Jul 2013 07:27:56 PM UTC, comment #2:

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/eefcfeb37446
fixes the issue on my system (ubuntu). The terminal already aborted a command with the copy shortcut but this was configured to ctrl+shift+c up to now. Just configuring to the right shortcut ctrl+c solved the problem.

I am leaving the report open until the fix is confirmed on other systems.

Torsten <ttl>
Project Member
Fri 24 May 2013 08:57:50 PM UTC, comment #1:

I just recently build the mxe-octave version for Windows. To my surprise the Windows version reacted correctly to the STRG+C by aborting the script. The Linux Octave Gui is still affected though...

Unfortunately I have no idea how to fix this...

Thorsten Liebig <thorsten>
Tue 06 Nov 2012 09:03:06 AM UTC, original submission:

If running a long command or script within the new Octave GUI it cannot be aborted with CTRL+C (or any other way) since it is not recognized!

I like the new GUI very much, but I run very lengthy numerical simulations and not being able to abort them is a real show-stopper for me. I have to kill (no reacting to quit or CTRL+Q either) the GUI and restart every time losing my workspace & results in the process...

I have tested this with the latest hg version on Linux.
"octave --no-gui" is not affected of course.
(http://hg.savannah.gnu.org/hgweb/octave/rev/80a4ded6b89c)

Thorsten Liebig <thorsten>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by ttl (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 03 Aug 2014 03:24:37 PM UTCrik5Carbon-CopyRemoved 72865=>-
    Fri 24 Jan 2014 08:19:13 PM UTCmtmillerItem GroupRegression=>Incorrect Result
    Mon 25 Nov 2013 09:38:26 PM UTCjweAttached File-=>Added diffs-system-interrupt.txt, #29713
    Thu 21 Nov 2013 04:34:58 PM UTCrik5Severity5 - Blocker=>4 - Important
    Fri 08 Nov 2013 04:47:00 PM UTCjweSeverity3 - Normal=>5 - Blocker
    Sun 28 Jul 2013 07:39:23 PM UTCmtmillerDependencies-=>bugs #37468 is dependent
    Sun 28 Jul 2013 07:38:47 PM UTCmtmillerStatusReady For Test=>Confirmed
    Thu 11 Jul 2013 07:27:56 PM UTCttlStatusConfirmed=>Ready For Test
    Wed 29 May 2013 08:05:22 PM UTCrik5Carbon-CopyRemoved 72865=>-
    Thu 11 Apr 2013 12:26:44 AM UTCrik5StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup