WindowsError: exception: access violation writing 0x00000004​

[David]

I used a combination of builder and coder version 1.81.02 to build my experiment. I tried running it on computers that had 1.82 and received the error in the subject line about 10 to 15 minutes into the experiment. I replaced 1.82 with 1.81.02 on those computers to see if it was a compatibility issue, but continue to get the same error. Does anybody know what this is?

All systems are running Windows 8.

[David]

A brief update:

Updating 1.81.02 to 1.82 on the original computer does not harm the completion of the experiment.

[David]

Here is the rest of the error code:

Traceback (most recent call last):

  File "C:\Users\dpl\Desktop\GlobalTimeExp1\GlobalTime1.py", line 3570, in <module>

    win.flip()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\psychopy-1.81.02-py2.7.egg\psychopy\visual\window.py", line 539, in flip

    thisStim.draw()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\psychopy-1.81.02-py2.7.egg\psychopy\visual\text.py", line 591, in draw

    self._pygletTextObj.draw()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\font\__init__.py", line 565, in draw

    self._layout.draw()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\text\layout.py", line 852, in draw

    self.batch.draw()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics\__init__.py", line 544, in draw

    func()

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics\__init__.py", line 476, in <lambda>

    (lambda d, m: lambda: d.draw(m))(domain, mode))

  File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics\vertexdomain.py", line 313, in draw

    glDrawArrays(mode, starts[0], sizes[0])

WindowsError: exception: access violation writing 0x00000004​

[Linh Dang]

Hello,

Did you or anyone else figure out what the problem was? I have several tasks that work perfectly well on a Mac. I then tried to run these same tasks on a Windows PC and received these exact errors. Both the Mac and Windows PC have Psychopy v. 1.82.

I'd really appreciate any suggestions for resolving this issue.

Thanks!

Linh

[Zach Howard]

Hi David, 

I am also having this exact error on a previously working experiment, the error happened when I used a longer stimulus list. Did you manage to fix this issue?

[Michael MacAskill]

This isolated error line is too generic for anyone to give to give a useful response. Can you provide the full text of the error report, and description of what is happening when the error arises?

Regards,

Michael

[Zach Howard]

Hi Michael, I have posted the full error output below. Basically, the experiment consists of presenting TWO text events (one word each), and recording text entry through a third text event using a bit of code I found here in the discussions. I loop through the presented words using an excel file. When I had only 48 trials the experiment ran fine, when I ran 480 the experiment crashes after 120 odd trials, always with the following error. The experiment seems to run fine on computers with a dedicated graphics card, suggesting it may be an issue related to Intel HD on board graphics, although I cannot figure out why it would run so many trials without error if this were the case. If this were the issue it could also explain why David's experiment ran on the original computer but not the other ones. I have tried several different Intel drivers, both the generic Intel driver and the Dell OEM driver (as my laptop is Dell branded).

Thanks,

The full error code is:

Traceback (most recent call last):

File "C:\Users\c3145114\Dropbox\PhD\Intersection in Memory\PsycoPy\SFT_Intersection\Final_SFT_Intersection_lastrun.py", line 2182, in 
win.flip()
File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\psychopy-1.82.01-py2.7.egg\psychopy\visual\window.py", line 539, in flip
thisStim.draw()
File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\psychopy-1.82.01-py2.7.egg\psychopy\visual\text.py", line 591, in draw
self.pygletTextObj.draw()
File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\font__init_.py", line 565, in draw
self.layout.draw()

File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\text\layout.py", line 852, in draw
self.batch.draw()

File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics__init_.py", line 544, in draw
func()
File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics__init__.py", line 476, in 

(lambda d, m: lambda: d.draw(m))(domain, mode))
File "C:\Program Files (x86)\PsychoPy2\lib\site-packages\pyglet\graphics\vertexdomain.py", line 313, in draw
glDrawArrays(mode, starts[0], sizes[0])
WindowsError: exception: access violation writing 0x00000004

[Michael MacAskill]

Hi Zach,

Thanks, that is much more useful. The strong recommendation is to use PsychoPy with a dedicated graphics card, most particularly on Windows. The error message, and the fact that it occurs only after 120 trials, shows that it is some sort of progressive memory issue. Integrated graphics cards usually share the same RAM as the software and operating system on your computer, rather than a proper graphics card, which has its own dedicated memory. And under Windows, those cards often don't support OpenGL very well, which PsychoPy relies upon, and which presumably handles these memory issues better.

As the integrated cards on Macs generally work well, it seems that the problem is often with the drivers concerned. You've done the right thing by trying to update those, and going to the source rather than relying on the Windows update mechanism. Since that hasn't resolved your problem, I think the only solution is to use a system with a dedicated graphics card. One wouldn't think that just displaying simple text stimuli would cause problems, but I guess that is an illustration of the problems with these integrated components, at least under Windows.

Someone who understands the hardware issues better than me may be able to give you better guidance, however.

Regards,

Michael

[Zach Howard]

Cheers Michael,

I'll definitely be running the experiment with a dedicated GPU, I am just writing the experiment on a laptop that doesn't have one. I'll just keep working with the smaller number of trials and make sure to test on a desktop PC before data collection.

Thanks for your quick and helpful response!

[Zach Howard]

Hi Michael (and others),

Unfortunately I've now hit this issue on a desktop, I've made a new post here if anyone is interested. Basically, it seems that no matter what GPU you use, psychopy is continuously building up video memory usage until it maxes out when drawing these text stimuli, which is when these issues occur. I need to find a way to clear the video memory before this happens, but I haven't been able to so far. Any help would be appreciated, we're supposed to be running this experiment at the moment!

On Thursday, May 7, 2015 at 12:16:59 PM UTC+10, Michael MacAskill wrote:

[Jonathan Peirce]

For my part I'm not quite saying that this is an intel graphics problem, only that I can't replicate it on my machines. I can set the text in a loop for 100s of iterations without getting a memory error.

Unfortunately until I can replicate the problem on a computer it's really hard for me to work out where the issue lies. (compare with the MovieStim2 issue, which I have now been able to replicate and so hope to be able to fix shortly).

As an alternative, if you're writing code rather than using builder you could use Sol Simpson's TextBox stimulus. It's limited in the fonts it can use (only monospace) but is considerably faster and uses a totally different text-rendering engine (he wrote it pretty much from scratch whereas the other one comes from pyglet).

I'll continue to scout around for a machine where I can replicate your problem locally though

best wishes
Jon

--
You received this message because you are subscribed to the Google Groups "psychopy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-user...@googlegroups.com.
To post to this group, send email to psychop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/psychopy-users/bac5e1a7-7846-4334-8d68-8685254c76ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Jonathan Peirce
University of Nottingham

http://www.peirce.org.uk

This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

[Zach Howard]

Hi Jon,

Have you encountered the memory spike I outlined in the discussion I made today (linked above)? This seems to be the root of the issue, it's just that the intel card in my laptop has a much lower memory threshold. As I detailed in my discussion today, the whole time psychopy continues to draw text the video memory usage increases dramatically (several megabytes a second using the above code), suggesting there is a lack of 'cleanup' happening. Obviously this affects on-board graphics more because there is little dedicated video memory, but after an hour of experiment session today the same thing occurred on our labs desktop with dedicated graphics.It is important to note that although the above code seems like it is only trying to 'break the system', it is actually a pretty good reflection of what happens in my experiment, which dynamically updates the text item with user input, thus requiring many draw text calls a second.

Also, I'm only using the builder view at the moment, as I haven't had the time to fully learn the coding, just snippets here and there unfortunately.

Cheers,

[Jonathan Peirce]

I haven't installed GPU-Z yet (my machine is currently booted in linux and it looks like GPU-Z is windows only).
I think you might well be correct that the issue is about memory and my graphics card is just taking too long to fill it. I'll look into it when I get a chance.

cheers
Jon

To view this discussion on the web visit https://groups.google.com/d/msgid/psychopy-users/7f8cb58c-b704-4342-944f-c6fc8f5e6e60%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Zach Howard]

Appreciated. There's probably a Linux alternative, I imagine it's a pretty standard thing to look at. In the meantime,is there a way that I could manually clear the video memory? I experience the crash three quarters through the experiment in the lab,so if I could just delay the issue a little bit I could still collect data...

Cheers
Zach Howard

[Jonathan Peirce]

No, the only thing that I no how to clear in this instance is the
display list that Psychopy is using. I'm assuming this is to do with a
texture that the pyglet text handler is using and not clearing but
without knowing what that texture id is we can't empty it

[Zach Howard]

I don't suppose you have found anything else I could try? I've added gc.collect and psychopy.event.clearEvents after each trial, but the memory usage still spikes, and it gets much worse if you actually type text (as opposed to letting skipping through a trial by pressing the enter response key). I've googled around but can't find a 'clear pyglet memory' command anywhere. I'd really like to be collecting data with this experiment ASAP as there is an honors student attached to the project.

[Michael MacAskill]

> On 10/06/2015, at 12:56, Zach Howard <how...@gmail.com> wrote:
>
> I don't suppose you have found anything else I could try?

Not sure if you are using Builder or Coder, but have you tried visual.TextBox as an alternative to visual.TextStim? It isn't exposed graphically as an option in Builder yet. Nonetheless, it could be created and manipulated in Builder via Code components. I think it entirely avoids pyglet and is designed to have much better performance. A tradeoff is that it allows only monospaced fonts.

Under the Coder Demos -> Stimuli menu, there are three TextBox examples.

> I've added gc.collect and psychopy.event.clearEvents after each trial

I don't think that either of those would help with this issue. And probably best to remove the manual gc.collect call and let that happen automatically.

Regards,

Michael

[Zach Howard]

Thanks Michael, I'm unforunately using the Builder interface as I'm not proficient enough to use the coder, but this sounds promising! Could you perhaps give me a little direction as to how I might implement it through the builder? At the moment, for my 'Text Input' event, I have a text event with "$('\n' + inputText)" as the 'text', and a code event that dynamically updates 'inputText' as the user presses keys. I found this on these forums and on the gitHub page (I think perhaps you were even the one who provided it?). 

How would I go about changing this event so that it was a TextBox instead?

[Zach Howard]

Also, I seem to be getting a 'shared context' gl error when trying to use this command, is that a limitation of my Intel graphics again??

[Michael MacAskill]

> On 10/06/2015, at 13:38, Zach Howard <how...@gmail.com> wrote:
>
> Thanks Michael, I'm unforunately using the Builder interface as I'm not proficient enough to use the coder, but this sounds promising! Could you perhaps give me a little direction as to how I might implement it through the builder? At the moment, for my 'Text Input' event, I have a text event with "$('\n' + inputText)" as the 'text', and a code event that dynamically updates 'inputText' as the user presses keys. I found this on these forums and on the gitHub page (I think perhaps you were even the one who provided it?).
>
> How would I go about changing this event so that it was a TextBox instead?

Delete your existing graphical text stimulus component. In its place, you will need to create and then update a TextBox stimulus entirely in code. I've never actually used a TextBox, so take all of this with a pinch of salt.

It seems you already have a Code component. In its "Begin Experiment" tab, put something like this:

# amend the settings to be whatever you need:
textBox_1 = visual.TextBox(window=win,
text='Hello, some dummy text to be replaced later',
font_size=21,
font_color=[-1,-1,1],
size=(0.5,0.25),
pos=(0.0,0.0),
grid_horz_justification='center',
units='norm',
)

Then in your existing code, after you create the variable 'inputText', insert this:

textBox_1.setText(inputText)
textBox_1.draw()


Having said that, I just tried to run the Coder TextBox demos, and they all fail like this:

File "/Applications/PsychoPy2.app/Contents/Resources/lib/python2.7/psychopy/demos/coder/stimuli/textBoxStim/textbox_glyph_placement.py", line 31, in <module>
textbox=visual.TextBox(window=window,
AttributeError: 'module' object has no attribute 'TextBox'

** It looks like TextBox has fallen foul of some of the recent re-organisation of stimuli in the source code. Any comment from other developers on this? **

Regards,

Michael

[Zach Howard]

Thanks Michael,

I can run the demos OK (at least they show text and seem to work), but as I said I am getting a shared context error on my laptop, I've just moved to a desktop with Radeon graphics to see if I can get a better result.

[Zach Howard]

Michael, I have got the TextBox working on the Desktop, but every time I type text I get the following error: "TextBox.setText only accepts strings with a length > 0"

I set the text to only update if len(inputText>0) but this did not work, still get nthe crash. If i don't type, the text box stays on screen (empty of course) until the event finishes.

[Michael MacAskill]

> On 10/06/2015, at 15:41, Zach Howard <how...@gmail.com> wrote:
>
> Michael, I have got the TextBox working on the Desktop, but every time I type text I get the following error: "TextBox.setText only accepts strings with a length > 0"
>
> I set the text to only update if len(inputText>0) but this did not work, still get nthe crash. If i don't type, the text box stays on screen (empty of course) until the event finishes.

This is likely just a logic problem but we can't help debug this without seeing your actual code. You could also liberally scatter some debugging statements like:

print(inputText)

to see what is happening at various points in your code.

Regards,

Michael

[Zach Howard]

I think it was because the input field STARTS blank, which it didn't like. I resolved this by creating a 'dispText' variable that starts with a space, then displaying this IF inputText is empty, and that fixed the problem. Thanks to your suggestions, my code now seems to be working with the TextBox instead of TextStim, which I'm hoping can fix the memory related crash. Unfortunately I don't have admin privileges on this desktop so GPU-Z won't run, thus I can't actually monitor the memory usage to see if it has decreased.

My one concern now is that, even when setting "grid_horz_justification='center'" for the 'top' and 'bottom' stimulus words, they don't nicely line up like they do with the TextStim option. Both have "x pos" set to 0 in the TextBox code. Is this just because of the monospace fonts? I've attached screenshots showing what i mean, notice how the bottom word seems to go further to the left than the right in the TextBox code, whereas in the TextStim screenshot the words both seem to start from the center of the screen...

If I could get these centered, I could eliminate the TextStim calls entirely from the main experiment, keeping it only for the instructions, which should eliminate any potential memory problems.

[Michael MacAskill]

> On 10/06/2015, at 16:59, Zach Howard <how...@gmail.com> wrote:
>
> My one concern now is that, even when setting "grid_horz_justification='center'" for the 'top' and 'bottom' stimulus words, they don't nicely line up like they do with the TextStim option. Both have "x pos" set to 0 in the TextBox code. Is this just because of the monospace fonts? I've attached screenshots showing what i mean, notice how the bottom word seems to go further to the left than the right in the TextBox code, whereas in the TextStim screenshot the words both seem to start from the center of the screen...

I really don't know anything about this stimulus, but I think one of the key things it can do is allow us to align text on a per-character basis (the individual characters in your example are perfectly aligned vertically). I guess that means it isn't going to be possible to centre text on a word-by-word basis if one word has an even number of characters and the other has an odd number (as here)? Although perhaps you could fudge things by adding a space at either end of one of the words.

Regards,

Michael

[Zach Howard]

MM, it looks like it is forced into using a grid layout. I'll just stick with using the TextStim for these (only drawn once per trial, so shouldn't have too big a memory footprint). Thanks so much for your help Michael, I think we may have gotten to a point where I can run this experiment!

[Zach Howard]

For anyone interested, I have re-rerun the 'test' code that generates many text events, using the TextBox command. No memory leak whatsoever.

Code:

from psychopy import visual, event

win = visual.Window()

i = 0

t=visual.TextBox(window=win,

                 text=str(i),

                 font_size=40,

                 font_color=[1,1,1],

                 size=(.5,.25),

                 pos=(0.0,0.075),

                 grid_horz_justification='center',

                 units='norm',

                 )

while True:

  t.setText(str(i))

  t.draw()

  win.flip()

  i += 1