dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
Date: Mon, 07 Jul 2014 19:38:50 +0000	[thread overview]
Message-ID: <bug-80673-502-UfYV8SEOtU@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-80673-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 1880 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=80673

--- Comment #8 from Hadrien <freedesktop@psydk.org> ---
It seems that what is happening is that the "end" argument is referencing a
vertex that does not exist when glDrawRangeElementsBaseVertex is called. The
documentation says that "start" and "end" are inclusive indices so I guess a
missing "-1" in the game code is the cause of the problem.

In the last callstack, the game informs the driver that vertices 0 to 64
(inclusive) should be used for drawing:
vbo_exec_DrawRangeElementsBaseVertex(mode=4, start=0, end=64, count=168,
type=5123, indices=0x7f22c87bfeb0, basevertex=0)

And later the driver will upload data with those arguments:
u_vbuf_upload_buffers(mgr=0x7f22efa9e760, start_vertex=0, num_vertices=65,
start_instance=0, num_instances=1) 

So an attempt to upload 65 vertices is done for a range of [0..64], which is
correct as per the spec, but in my case the buffer only holds 64 elements.

I do not know how the driver can protect itself from such a case. I've been
looking at the glVertexPointer API but the client does not inform the driver of
the total size of the pointed buffer, so I don't know how to verify this kind
of out of bounds errors.

The only idea I have would be to scan all indices to get min and max values and
issue a warning if they do not fit exactly in the "start" and "end" indices.
However this would probably be ineffective as the purpose of "Range" functions
seems to be precisely to inform the driver of the range so it does not need to
compute it. Moreover, though it is ineffective to include useless vertices in
the range, the spec does not seem to forbid it.

Sadly, it seems there is nothing to do on the Mesa side. At least I will inform
the game developers about my analysis and then close this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2746 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2014-07-07 19:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-29 11:46 [Bug 80673] New: XCOM: Enemy Unknown - Wrong read access when starting the game bugzilla-daemon
2014-06-29 11:47 ` [Bug 80673] " bugzilla-daemon
2014-06-29 14:26 ` bugzilla-daemon
2014-06-30 17:01 ` bugzilla-daemon
2014-06-30 17:24 ` bugzilla-daemon
2014-07-06 14:19 ` bugzilla-daemon
2014-07-06 18:21 ` bugzilla-daemon
2014-07-06 18:23 ` bugzilla-daemon
2014-07-07 19:38 ` bugzilla-daemon [this message]
2014-07-08 18:37 ` bugzilla-daemon
2014-07-08 19:28 ` bugzilla-daemon
2014-08-13 10:41 ` bugzilla-daemon
2016-04-12  7:16 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-80673-502-UfYV8SEOtU@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox