Re: Errors locking offscreen surface if application heap is large

interesting problem.

DX7 still should have good debug output, have you turned the debug level all
the way up? DX7 you may still need to do this via the ini file, its been so
long since I worked with DX7 exclusively I cant recall.

just as an FYI, Surface.GetDC does a lock. If you comment out all your
GetDC/ReleaseDC code, does the failure go away? That would isolate this to
the DX-GDI interface. If so, one possible solution is to rewrite all your
text painting code to use D3D. Do you ever issue simultaneous locks?

"DmitriAtSun@xxxxxxxxxxxxxxxxx"
<DmitriAtSunnewsgroupsnospam@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6BF856BA-D16C-41EC-A836-2F4265744353@xxxxxxxxxxxxxxxx
>
> Thanks for your response.
>
> "Phil Taylor" wrote:
>
>> hard to say. I think the analysis in the report is suspect, its certainly
>> not related to some crufty old NT 4.0 DDraw 3.0 bug.
>
> That's just something (relatively) relevant we were able to find
> regarding
> this error by searching in msdn and other places.
>
>> how many machines tested on? whats the memory map for the machines, to
>
> Plenty, with different hw/os configurations, so this is not uncommon.
> Depending on systems' memory configuration the java's heap setting at
> which
> the failure occurs could be different. On my 1.5G WinXP (Dell precision
> 530?)
> it happens if more than 1.5G heap is requested.
>
> On another completely different system is my notebook (Dell 700m with
> 500m
> of ram with Intel i815 chipset), the failure point is something like 700
> megs).
>
> Basically, I'm pretty sure I can reproduce it on any system given some
> time
> to find the right heap setting.
>
>> understand whats already loaded into the process address space? and what
>> is
>> the largest contiguous block? and what are the physical and virtual
>> memory
>> settings? and whats the graphics hw/driver? all drivers for this hw show
>> this problem?
>
> I'll get back to you with the memory mapping settings, but I can
> reproduce
> the problem on my system with different video boards (nvidia, ati), so I
> doubt
> that this is a driver-specific issue.
>
>> on average, though, its hard to assume you can allocate more than 50% of
>> the
>> address space, which you are getting. at some point above that, things
>> begin
>> to fail.
>>
>> its not clear if its DDraw, or GDI since it appears a GetDC on a DDraw
>> surface is what fails based on comments, code is not forthcoming. its
>> also
>> not clear if its specific to a card/driver or machine config.
>
> Well, the most visible failure is actually the one that comes from the
> failing Lock.
>
>> this is going to be a hard bug to analyze. you need a few machines with a
>> few different memory configs, and a few different graphics card configs,
>> and
>> experiment.
>
> I realize that. Thanks for your help. As I mentioned, we've reproduced it
> on
> several systems (including a couple of notebooks, with intel and ati
> chipsets).
>
>> and run the app on a machine with the debug DX installed, and run the app
>> in
>> the debugger to capture the debug spew.
>
> I do have debug DX installed, but since we use DX7 there's not much
> we can capture.
>
> Thanks,
> Dmitri
>
>
>>
>> perhaps that more detail will let an accurate analysis of the problem
>> take
>> place.
>
>
>
>>
>>
>> "DmitriAtSun@xxxxxxxxxxxxxxxxx"
>> <DmitriAtSun@xxxxxxxxxxxxxxxxx@discussions.microsoft.com> wrote in
>> message
>> news:EB19CF77-9BAC-4FBA-A422-655B6A89529E@xxxxxxxxxxxxxxxx
>> > Hello,
>> >
>> > I have an application (it's Sun's java implementation) which could in
>> > some
>> > cases
>> > reserve large pieces of memory for heap and other stuff if requested by
>> > users.
>> >
>> > The app is DirectX7-based. We load ddraw.dll with LoadLibrary (and the
>> > call
>> > succeeds).
>> >
>> > In these conditions I see calls to Lock a plain offscrreen surface
>> > fail
>> > with DDERR_GENERIC, and also GetDC on offscreen surfaces fail
>> > occasionally
>> > with DDERR_CANTCREATEDC.
>> >
>> > For additional details, take a look at this bug report:
>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6353972
>> >
>> > My question is: first, why would Lock fail in these conditions? Is this
>> > expected
>> > behavior?
>> >
>> > And second: is there any way to detect a situation when ddraw could
>> > fail
>> > because of (presumably) address space exaustion?
>> >
>> > Thanks,
>> > Dmitri
>> >
>>
>>
>>


.

Relevant Pages

  • [UNIX] PHP gd Library imageRotate() Function Information Leak Vulnerability
    ... PHP gd Library imageRotateFunction Information Leak Vulnerability ... Information leak vulnerabilities allow access to e.g. the Apache memory ... gdImagePtr gdImageRotate (gdImagePtr src, double dAngle, ... if($debug) ...
    (Securiteam)
  • Re: Problem only in release version!
    ... Debug version may still have the problem, but the stack space is better ... memory or a buffer on the stack is not always caught. ... > Just to affirm Jochen's point, the Debug version initializes most ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Epia Mini-ITX ce installation
    ... run your apllication on the CE simulator, or maybe even when you try to ... Normally the Emulator emulates a device with 32MB ram memory. ... A debug CE image is roughly about twice the size of a retail image. ...
    (microsoft.public.windowsce.embedded)
  • Changing the config.bib file
    ... I need to know how to address memory less than 1Mb ... internal SRAM ... There is no need to put 32KB SRAM into the OEM address table unless ... Do a debug build to see where you are ...
    (microsoft.public.windowsce.embedded)
  • Re: Need help with own PXE/bootloader and SDI images
    ... If the problem is in NT Loader, switching to serial debug may show some good ... that SDI is loaded in memory where it is expected. ... reallocate the ...
    (microsoft.public.windowsxp.embedded)