PureBasic Forums - English

Posted: **Tue Jul 29, 2014 7:57 pm**

System:

PureBasic 5.30 Beta 9 (Linux - x86)
Distro: elementary OS: 0.2.1 "Luna"(32-bit)
Based on: Ubuntu 12.04("Precise")
Intel Core 2 CPU 6300 @ 1.86ghz x 2
Memory: 2gb

Library/Command/Function involved:

Library: Clipboard
Command: GetClipboardText()

Symptom:

Continuously polling the clipboard with GetClipboardText() in a loop, with or without any time delay eventually causes program to lag and eventually stall for undesirable amounts of time. Amount of time until effect took place varied from a few minutes to 10 minutes.

Example Code:

Code: Select all

  OpenWindow(0,60,60,220,200,"Clipboard Bug?",#PB_Window_SystemMenu|#PB_Window_TitleBar)
  TextGadget(0,10,10,290,30,"0")
  ListViewGadget(1,10,50,200,140)
  vClipBoardData$ = GetClipboardText()
  ; ----------------------------------
  Repeat 
    vWindowEvent = WindowEvent()
    Delay(100)
    vClipBoardDataTemp$ = GetClipboardText()
    If vClipBoardDataTemp$ <> vClipBoardData$
      vClipBoardData$ = vClipBoardDataTemp$
      AddGadgetItem(1,0,vClipBoardData$)
    EndIf
    SetGadgetText(0,Str(ElapsedMilliseconds()))
  Until vWindowEvent = #PB_Event_CloseWindow

Notes:

I do not have any other systems to test this on or against, so I can't confirm if it's a system specific issue. But, doing the same exact thing in another language I used to use under Wine doesn't suffer from this.. I don't have any other Linux based programming languages to test with right now either or I would have.

I actually have written this code several times using different coding styles, Goto, Gosub, Function, Procedure and just right in the repeat loop as well, all with the same results. I also let the code run while I was interacting with other programs as well as let it run without my interaction with anything else at all and the results were the same. What I didn't try was clearing the clipboard to see if the effect would still happen with an empty clipboard.

What I was trying to accomplish is to keep an eye on the clipboard for text, which was to be the title of software, test that text with a regex against a small database file of software titles to see if the title existed already in the database.

Best regards,
~Garrett

Posted: **Tue Jul 29, 2014 8:16 pm**

Possibly your event queue gets full? You only process 1 event on every loop, and with the Delay(100) you process
only 10 events per second. Maybe the AddGadgetItem() produces several events (like updating/redrawing etc).

Try catching all events for every loop, or even better: Move the clipboard polling to a timer with 100ms.

Posted: **Tue Jul 29, 2014 9:09 pm**

Or use

Code: Select all

vWindowEvent = WaitWindowEvent(100)

and remove the Delay(100)

Bernd

Posted: **Tue Jul 29, 2014 9:33 pm**

Will try the suggestions.

BTW..I may have been slightly premature in my post. I could swear that I had no userlibs sitting in there, but did another check... After The Post and found 3 userlibs still left in there. removed them and am currently running the program now.

<---- feels like an old stupid coot now.

Posted: **Tue Jul 29, 2014 9:55 pm**

After clearing the userlibs and restarting the compiler, I ran the program for near 40 minutes without any interaction by myself on the computer. Came back and started to randomly copy single words of text from various programs. After about 5 minutes, the lag effect began and was shortly followed by being stalled for 30 to 60 seconds.

I have now changed the code to remove the delay and use the WaitWindowEvent(100)

Code: Select all

  OpenWindow(0,60,60,220,200,"Clipboard Bug?",#PB_Window_SystemMenu|#PB_Window_TitleBar)
  TextGadget(0,10,10,290,30,"0")
  ListViewGadget(1,10,50,200,140)
  vClipBoardData$ = GetClipboardText()
  ; ----------------------------------
  Repeat 
    vWindowEvent = WaitWindowEvent(100)
    vClipBoardDataTemp$ = GetClipboardText()
    If vClipBoardDataTemp$ <> vClipBoardData$
      vClipBoardData$ = vClipBoardDataTemp$
      AddGadgetItem(1,0,vClipBoardData$)
      SetGadgetState(1,0)
    EndIf
    SetGadgetText(0,Str(ElapsedMilliseconds()))
  Until vWindowEvent = #PB_Event_CloseWindow

BTW, I've been running the program in compiled form and not from the IDE.

Thanks,
~Garrett

Posted: **Tue Jul 29, 2014 10:13 pm**

BTW, just an off the side observation.

Delay(100) = 1% cpu
WaitWindowEvent(100) = 45% cpu

About 5 or 10 minutes into latest run and have already experience a short stall and am noticing some slight delays in the looping now.

Posted: **Tue Jul 29, 2014 11:25 pm**

Alright, done testing. Even after changes, emptied userlibs, compiler restart, program recompiled, it still suffers from occasional lag and stalls. I also tested with a time log of any delays of over 200ms. the lags usually lasted 200 to 300ms and the stalls typically lasted a minimum of 31000ms. Also tested while doing file intense operations on the system, such as decompressing a 4 gig tar file and trying to load that 4 gig xml file into an editor. During the decompressing the test program suffered no lags or stalls, but during the attempted loading of the 4 gig xml file into an editor the test program was riddled with lag hits and a few stalls.

Unless anyone else is able to use the following code to reproduce this problem, then I will have to mark it up as my system.

Code: Select all

  OpenWindow(0,60,60,220,200,"Clipboard Bug?",#PB_Window_SystemMenu|#PB_Window_TitleBar)
  TextGadget(0,10,10,290,30,"0")
  ListViewGadget(1,10,50,200,140)
  AddGadgetItem(1,0,"[ Start time:  " + FormatDate("%hh:%ii:%ss", Date()) + " ]")
  vClipBoardData$ = GetClipboardText()
  ; ----------------------------------
  Repeat 
    vWindowEvent = WaitWindowEvent(100)
    vTimeCurr = ElapsedMilliseconds()
    vTimeDiff = vTimeCurr - vTimePrev
    vClipBoardDataTemp$ = GetClipboardText()
    If vTimeDiff > 200
      AddGadgetItem(1,0,"[ " + FormatDate("%hh:%ii:%ss", Date()) + " ]-[ " + Str(vTimeDiff) + " ]")
      SetGadgetState(1,0)
    EndIf
    If vClipBoardDataTemp$ <> vClipBoardData$
      vClipBoardData$ = vClipBoardDataTemp$
      AddGadgetItem(1,0,vClipBoardData$)
      SetGadgetState(1,0)
    EndIf
    SetGadgetText(0,Str(ElapsedMilliseconds()))
    vTimePrev = vTimeCurr
  Until vWindowEvent = #PB_Event_CloseWindow

Best regards,
~Garrett

Posted: **Wed Jul 30, 2014 5:35 am**

Could you please test using timers? In the following code, GetClipboardText() is only called every 100 milliseconds.

Code: Select all

OpenWindow(0,60,60,220,200,"Clipboard Bug?",#PB_Window_SystemMenu|#PB_Window_TitleBar)
TextGadget(0,10,10,290,30,"0")
ListViewGadget(1,10,50,200,140)
AddGadgetItem(1,0,"[ Start time:  " + FormatDate("%hh:%ii:%ss", Date()) + " ]")

vClipBoardData$ = GetClipboardText()

AddWindowTimer(0,0,100)
AddWindowTimer(0,1,20)

; ----------------------------------
Repeat 
    vWindowEvent = WaitWindowEvent()
    If vWindowEvent = #PB_Event_Timer
        Select EventTimer()
            Case 0
                vClipBoardDataTemp$ = GetClipboardText()
                If vClipBoardDataTemp$ <> vClipBoardData$
                    vClipBoardData$ = vClipBoardDataTemp$
                    time.s = "[ " + FormatDate("%hh:%ii:%ss", Date()) + "] "
                    AddGadgetItem(1,0,time + vClipBoardData$)
                    SetGadgetState(1,0)
                EndIf
            Case 1
                SetGadgetText(0,Str(ElapsedMilliseconds()))
        EndSelect
    EndIf
Until vWindowEvent = #PB_Event_CloseWindow

BTW: WaitWindowEvent(100) does not mean it is always waiting 100 milliseconds. If events arrive, they get
processed immediately. It just waits 100ms when no events occur. That means, with your old code, GetClipboardText()
could get called every millisecond (or more), if any events (f.e. mouse movement) arrive. With timers you don't need that.

When loading a 4GB file all-at-once into memory, a lag could occur when you run out of memory. In this case, the system could start to
swap out memory to HDD (swap partition on Linux). It depends on how much memory your PC has, and if you are using 32bit or 64bit Linux OS,
and 32bit or 64bit PureBasic (in your case, your process does not require much memory, it is just the strings that get added to the ListViewGadget
that add memory over time). That would be a system issue, and other programs should also show the lag, if it gives priority to the loading
of the big 4GB file and starts to swap out memory of other processes.

Posted: **Wed Jul 30, 2014 6:15 am**

Will test with your code in the morning.

Posted: **Wed Jul 30, 2014 10:38 pm**

@Danilo

Testing with the timers almost alleviated the problem. The program did not suffer the little lags, but after two hours of running and some casual use on my computer, it eventually was hit with two stalls a few minutes apart, otherwise, this was far better than any of my previous results.

I'm still not sure if this is a bug or something to do with my system. It's a pretty clean system, in fact, I only recently wiped this computer and installed Linux on it. While it's based on a slightly older version of Ubuntu, it is updated with all the latest updates available for this distro. So, unless anyone else is able to get similar results to mine, I just have no explanation, ideas or conclusions as to what the issue is.

Thanks to all of you who have tried to help me pinpoint this,
~Garrett

Posted: **Thu Sep 25, 2014 7:14 pm**

Its not a bug. Your problem doesn't even have anything to do with the clipboard functions.

If you use the example from the first post and comment out all clipboard stuff, the problem will be even worse. You are simply generating more events that you are handling because of the SetGadgetText() call.

On each iteration, your mainloop does this:
1) consume one event with WindowEvent()
2) call SetGadgetText() which will produce more events (for redrawing etc).

This way, the events keep piling up until the program seems to hang. Your later example with WaitWindowEvent() and a timeout still has the same problem: for each processed event, more events are generated.

This is why the timer examply by Danilo works: Now, SetGadgetText() is called less times than events are being processed, so the event queue has a chance to catch up.

Posted: **Thu Sep 25, 2014 7:28 pm**

Ever since playing Minecraft, I have cursed Java's garbage collector, because programmers don't take care of their useless data anymore and when the GC kicks in, it slows down the program immensely. But now see what happens when programmers don't take care of their data and there is NO garbage collector...

Posted: **Thu Sep 25, 2014 8:19 pm**

A garbage collector wouldn't help you here because the events are not garbage. They are waiting in the queue to be processed.

Posted: **Thu Sep 25, 2014 8:32 pm**

Thanks for clarifying.
When PB returns/exits a Procedure that created arrays or big strings internally, are those freed immediately or at program termination?

Posted: **Fri Sep 26, 2014 10:10 am**

They are freed immediately on procedure exits.

PureBasic Forums - English

Clipboard Bug?

Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?

Re: Clipboard Bug?