Bug Tracker – Bug 224

Remote Door Server/Client Disagreement

Last modified: 2011-05-19 02:44:56 UTC
Bug 224 - Remote Door Server/Client Disagreement
Summary: Remote Door Server/Client Disagreement
Status: RESOLVED FIXED
Alias: None
Product: Odamex
Classification: Unclassified
Component: Server & Client (show other bugs)
Version: (old) 0.0.1
Hardware: x86 (Windows, Linux, etc) Windows (Any)
: P2 normal
Assignee: Denis Lukianov
URL:
: 291 (view as bug list)
Depends on:
Blocks: 424 620
  Show dependency tree
 
Reported: 2006-10-01 19:15 UTC by Ralph Vickers
Modified: 2011-05-19 02:44 UTC (History)
2 users (show)

See Also:

Attachments

Client disagreements (279.06 KB, image/png)
2006-10-07 09:41 UTC, Dean Joseph
Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Vickers 2006-10-01 19:15:40 UTC
Environment experienced: 4+ Player FFA, UDM2 Map09

If a door that is activated either by shooting or remotely it will appear to not open on the client. However, the door does in fact open according to the client. Thus, the door appears closed to the player but they can walk through it.

A most likely related issue occured on UDM2 Map11. Opening the local door to the exit proved successful and the client and server seemed to agree. However, after going into the exit room, turning around and shutting the door it appeared to close client side. According to the server though it was still open.
Comment 1 Denis Lukianov 2006-10-01 19:41:24 UTC
Blame hexen removals
Comment 2 Dean Joseph 2006-10-04 01:36:35 UTC
This happens with all line specials. This is not specific to doors. Russell and myself have both witnessed this with lowered floors in doom2.wad MAP01.
Comment 3 Dean Joseph 2006-10-07 09:35:59 UTC
This bug can be known to cause crashes if the disagreement is severe enough. This backtrace occured while playing freedoom map30:

Program received signal SIGSEGV, Segmentation fault.
0x00440229 in rt_map1col_c(int, int, int, int) (hx=1, sx=617, yl=336, yh=336)
    at ../src/r_drawt.cpp:154
154                     *dest = colormap[*source];
(gdb) bt
#0  0x00440229 in rt_map1col_c(int, int, int, int) (hx=1, sx=617, yl=336,
    yh=336) at ../src/r_drawt.cpp:154
#1  0x00441305 in rt_draw1col(int, int) (hx=1, sx=617)
    at ../src/r_drawt.cpp:660
#2  0x00441843 in rt_draw4cols(int) (sx=616) at ../src/r_drawt.cpp:762
#3  0x004466f3 in R_RenderSegLoop2() () at ../src/r_segs.cpp:565
#4  0x00447814 in R_StoreWallRange(int, int) (start=499, stop=639)
    at ../src/r_segs.cpp:1025
#5  0x0043c968 in R_ClipSolidWallSegment(int, int) (first=499, last=639)
    at ../src/r_bsp.cpp:131
#6  0x0043db59 in R_AddLine(seg_s*) (line=0x24a12f8) at ../src/r_bsp.cpp:650
#7  0x0043e1f5 in R_Subsector(int) (num=1591) at ../src/r_bsp.cpp:859
#8  0x0043e33e in R_RenderBSPNode(int) (bspnum=34359) at ../src/r_bsp.cpp:891
#9  0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1583) at ../src/r_bsp.cpp:883
#10 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1586) at ../src/r_bsp.cpp:883
#11 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1587) at ../src/r_bsp.cpp:883
#12 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1588) at ../src/r_bsp.cpp:883
#13 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1628) at ../src/r_bsp.cpp:883
#14 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1858) at ../src/r_bsp.cpp:883
#15 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1859) at ../src/r_bsp.cpp:883
#16 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1860) at ../src/r_bsp.cpp:883
#17 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1861) at ../src/r_bsp.cpp:883
#18 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1863) at ../src/r_bsp.cpp:883
#19 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1864) at ../src/r_bsp.cpp:883
#20 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1993) at ../src/r_bsp.cpp:883
#21 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=1994) at ../src/r_bsp.cpp:883
#22 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=2239) at ../src/r_bsp.cpp:883
#23 0x0043e2e6 in R_RenderBSPNode(int) (bspnum=2484) at ../src/r_bsp.cpp:883
#24 0x00443a7d in R_RenderPlayerView(player_s*) (player=0x41911f8)
    at ../src/r_main.cpp:1008
#25 0x00417317 in D_Display() () at ../src/d_main.cpp:269
#26 0x0041766b in D_DoomLoop() () at ../src/d_main.cpp:385
#27 0x0041cc2d in D_DoomMain() () at ../src/d_main.cpp:1254
#28 0x004031b7 in SDL_main (argc=1, argv=0x22fd90) at i_main.cpp:155
#29 0x004946c6 in console_main (argc=1, argv=0x22fd90)
    at src/main/win32/SDL_win32_main.c:217
#30 0x00494887 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x241f03 "",
    sw=10) at src/main/win32/SDL_win32_main.c:353
#31 0x0049420a in main ()
(gdb)
Comment 4 Dean Joseph 2006-10-07 09:41:52 UTC
Created attachment 30 [details]
Client disagreements

One player, who activated the line, sees this as being open while the other sees it as being closed. Freedoom MAP29.

I've noticed that this bug occurs more frequently with single-activated lines instead of repeatables. While the attachment isn't probably the best case (as running two clients in debug on the same computer is certainly not ideal), exp[x] and myself have both noticed this while playing on the same server simultaneously.
Comment 5 Denis Lukianov 2006-10-09 09:53:39 UTC
Regarding the backtrace in comment 3, need to work out what was wrong at site of crash. Need more debug info. Was dest or colormap invalid? Were they NULL?
Comment 6 Dean Joseph 2006-10-31 21:03:16 UTC
I'll try and reproduce the crash later tonight, using the latest revision.
Comment 7 Dean Joseph 2007-01-22 16:40:43 UTC
*** Bug 291 has been marked as a duplicate of this bug. ***
Comment 8 Russell Rice 2009-02-03 05:44:18 UTC
Any updates on this? does it still crash?
Comment 9 Ralph Vickers 2010-01-15 06:12:51 UTC
I have not personally experienced any crashes in regards to this in a long time. However, the actual desync bug still exists as of r1431.
Comment 10 Ralph Vickers 2011-05-19 02:44:56 UTC
Haven't heard or seen anything on this in almost half a decade. I think this is safe to close.