View Issue Details

IDProjectCategoryView StatusLast Update
0000262Gameplay + OpenGL[All Projects] Bugpublic2017-02-14 08:47
ReporterEdward-san 
Assigned To 
PrioritynormalSeverityblockReproducibilityalways
Status resolvedResolutionfixed 
Summary0000262: "Attempt to write to buffer of hardware canvas" fatal error when opening the menu
DescriptionWhen I press ESC while in game, the program gets the fatal error "Attempt to write to buffer of hardware canvas".

It happens with sw renderer on Linux, though I believe it happens also on Windows if vid_hw2d is disabled.

Stack trace:


#0  I_FatalError (error=0xd53820 "Attempt to write to buffer of hardware canvas") at /home/edward-san/zdoom/gzdoom/trunk/src/posix/sdl/i_system.cpp:178

#1  0x0000000000ad414a in DCanvas::DrawTextureParms (this=0x3fca7a0, img=0x299e410, parms=...) at /home/edward-san/zdoom/gzdoom/trunk/src/v_draw.cpp:239

0000002  0x0000000000ad396b 
in DCanvas::DrawTexture (this=0x3fca7a0, img=0x299e410, x=94, y=2, args=...) at /home/edward-san/zdoom/gzdoom/trunk/src/v_draw.cpp:162

0000003  0x0000000000ad3ca1 
in AF__Screen_DrawTexture (param=0x32dd310, defaultparam=..., numparam=6, ret=0x7fffffffc8c0, numret=0) 
at /home/edward-san/zdoom/gzdoom/trunk/src/v_draw.cpp:175
0000004  
0x0000000000c1e5b9 in VMExec_Checked::Exec (stack=0x7ffff7f358a8, pc=0x2a2da44, ret=0x0, numret=0) at 
/home/edward-san/zdoom/gzdoom/trunk/src/scripting/vm/vmexec.h:657
0000005  
0x0000000000c3bb37 in VMFrameStack::Call (this=0x7ffff7f358a8, func=0x387a590, params=0x7fffffffca20, 
numparams=2, results=0x0, numresults=0, trap=0x0) at /home/edward-san/zdoom/gzdoom/trunk/src/scripting/vm/vmframe.cpp:466

0000006  0x00000000006e0d8c 
in DMenuItemBase::Drawer (this=0x2f6c2f0, selected=false) at /home/edward-san/zdoom/gzdoom/trunk/src/menu/menu.cpp:1335

0000007  
0x00000000006d71ea in DListMenu::Drawer (this=0x34c1970) at /home/edward-san/zdoom/gzdoom/trunk/src/menu/listmenu.cpp:269

0000008  0x00000000006dcdba 
in AF_DMenu_Ticker (param=0x7fffffffcbb0, defaultparam=..., numparam=1, ret=0x0, numret=0) at /home/edward-san/zdoom/gzdoom/trunk/src/menu/menu.cpp:384

0000009  0x0000000000c3ba65 
in VMFrameStack::Call (this=0x7ffff7f358a8, func=0x28ce680, params=0x7fffffffcbb0, numparams=1, results=0x0, 
numresults=0, trap=0x0) at /home/edward-san/zdoom/gzdoom/trunk/src/scripting/vm/vmframe.cpp:443
0000010 0x00000000006dcedf 
in DMenu::CallTicker (this=0x34c1970) at /home/edward-san/zdoom/gzdoom/trunk/src/menu/menu.cpp:393
0000011 
0x00000000006de9e3 in M_Ticker () at /home/edward-san/zdoom/gzdoom/trunk/src/menu/menu.cpp:872
0000012 
0x00000000008bb380 in TryRunTics () at /home/edward-san/zdoom/gzdoom/trunk/src/d_net.cpp:1945
0000013 
0x00000000008b0bc7 in D_DoomLoop () at /home/edward-san/zdoom/gzdoom/trunk/src/d_main.cpp:1017
0000014 
0x00000000008b4d75 in D_DoomMain () at /home/edward-san/zdoom/gzdoom/trunk/src/d_main.cpp:2687
0000015 
0x000000000061fd97 in main (argc=6, argv=0x7fffffffdeb8) at /home/edward-san/zdoom/gzdoom/trunk/src/posix/sdl/i_main.cpp:259

TagsNo tags attached.

Relationships

Activities

Graf Zahl

Graf Zahl

2017-02-13 15:46

administrator   ~0000561

I have absolutely no idea how this happens. Is it something new and if so, since when?
Edward-san

Edward-san

2017-02-13 15:56

developer   ~0000563

It happens since menu scriptification. I can't check which commit broke at the moment.
dpJudas

dpJudas

2017-02-13 19:56

developer   ~0000570

You can solve this by adding a canvas lock(true) at the top of DCanvas::DrawTextureParms and an unlock() at the bottom. That's how I fixed it in QZDoom.
Graf Zahl

Graf Zahl

2017-02-14 05:41

administrator   ~0000572

That would solve it on all backends, except DirectDraw, which has quite a complex locking mechanism and requires somewhat involved logic to switch between 3D and 2D.

I am really wondering if it is finally time to dump this code, we have already done lots of changes to bring the engine forward, this is really the last remaining piece of cruft for ancient hardware. Or may this break too many users on really old hardware? Currently the minimum system requirement is Windows XP SP3 which should be recent enough to assume that those machines have a basically functional 3D graphics card with first generation shader support.

I'd expect some people who actively try to make the engine work on Windows 98 not to be thrilled by such an outlook but this is a piece of code nobody here is willing to maintain anymore
Graf Zahl

Graf Zahl

2017-02-14 06:23

administrator   ~0000573

Fixed. This was caused by the Ticker method calling a draw function, which is not allowed. In the 2D subsystem of the engine these events require strict separation.

@dpJudas, please remove your hotfix again, it will only hide genuine problems from anybody using the system later and not result in stable execution.
dpJudas

dpJudas

2017-02-14 08:15

developer   ~0000574

Last edited: 2017-02-14 08:34

View 2 revisions

Okay, I changed my hotfix into an I_FatalError assertion checking if the canvas has been locked. Unfortunately this assertion triggers still after your Ticker fix was merged into QZDoom.

Call stack is as follows:
SWCanvas::DrawTexture(DCanvas*, FTexture*, DrawParms&) + 57
DCanvas::DrawTextureParms(FTexture*, DrawParms&) + 9
DCanvas::DrawTexture(FTexture*, double, double, int, ...) + 171
DSBarInfo::DrawGraphic(FTexture*, SBarInfoCoordinate, SBarInfoCoordinate, int, int, double, bool, bool, 
bool, int, bool, int, int, double const*, bool) const + 2736
CommandDrawImage::Draw(SBarInfoMainBlock const*, DSBarInfo const*) + 512
DSBarInfo::_Draw(EHudState) + 479
D_Display() + 1417
D_DoomLoop() + 383
D_DoomMain() + 8719


dpJudas

dpJudas

2017-02-14 08:31

developer   ~0000575

Last edited: 2017-02-14 08:47

View 2 revisions

About the DirectDraw code: I know half the code in that target is more or less dormant because all places call Lock with a true to that 'buffered' argument. That's one of the reasons I decided just doing the lock always would be harmless, even if it wasn't the cleanest way of fixing this problem.

About removing DirectDraw: Since Windows 98 did support Direct3D 9 the only ones affected would be people with hardware having no GPU capabilities at all. But even half the Direct3D 9 code is a convoluted mess that cannot be touched because it is fallback code to dinosaur shader models that I personally have no way of testing. It was the primary reason I could not finish that viewport patch, because changing how this code works in any way whatsoever involved abandoning the legacy support.

Issue History

Date Modified Username Field Change
2017-02-13 15:35 Edward-san New Issue
2017-02-13 15:46 Graf Zahl Note Added: 0000561
2017-02-13 15:56 Edward-san Note Added: 0000563
2017-02-13 19:56 dpJudas Note Added: 0000570
2017-02-14 05:41 Graf Zahl Note Added: 0000572
2017-02-14 06:23 Graf Zahl Note Added: 0000573
2017-02-14 06:24 Graf Zahl Status new => resolved
2017-02-14 06:24 Graf Zahl Resolution open => fixed
2017-02-14 08:15 dpJudas Note Added: 0000574
2017-02-14 08:31 dpJudas Note Added: 0000575
2017-02-14 08:34 dpJudas Note Edited: 0000574 View Revisions
2017-02-14 08:47 dpJudas Note Edited: 0000575 View Revisions