Do you have multiple monitors?  What are their configurations?  What settings are enabled in System Preferences -> Mission Control?

I tried with both single and dual monitors - neither worked.
Under System Preferences -> Mission Control I tried checking and
unchecking "Displays have separate spaces" - neither worked.

I don't usually use OS X El Capitan. The testing I did was on a
borrowed system to verify the bug. I am the author/maintainer of the
Adxv application and this problem was reported by a user. The user had
a single monitor.

With XQuartz 2.7.9_beta1, a user reported this:

$ adxv
=================================================================
==69127==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000100554ec8 at pc 0x0001008044b5 bp 0x
7fff5fbfaa10 sp 0x7fff5fbfaa08
READ of size 4 at 0x000100554ec8 thread T0

Is this a bug in Adxv or Xquartz?

I don't know, because you've not included the rest of the report, but regardless, it is not relevant to this ticket and should be tracked elsewhere.  Please ask on the mailing list for help or open a new ticket with the full report.

This is still not working in XQuartz 2.7.9_beta2

Well you might start by providing the rest of that crash report...

Also, when did the issue start occurring?

There is no crash, some windows are just not visible.
This is the same bug as my original bug report.
This has never worked in OSX 10.11 but always worked
in OSX 10.10

To see the problem, download the Adxv binary from here:

http://www.scripps.edu/~arvai/adxv/adxv_1.9.10/adxv.macOSX_10.11

From a Terminal window go to the Download folder and do:

chmod +x ./adxv.macOSX_10.11
./adxv.macOSX_10.11

Not all the X11 Windows will be displayed.
If you press F3 you can see the other windows.

What you provided in comment #3 is accompanied by a crash log in ~/Library/Logs/DiagnosticReports.  The relevant data is missing.  You only provided a snippet.

I ran adxv.macOSX_10.11, and I see two windows.  One is 'Adxv Load' and one is 'Adxv Control'.

There is one other window which is off-screen.  It is titled 'Adxv'  Running xwininfo on it reveals:

$ xwininfo -name Adxv -all

xwininfo: Window id: 0xc0026b "Adxv"

  Root window id: 0x141 (the root window) (has no name)
  Parent window id: 0x80000d (has no name)
     1 child:
     0xc0026c (has no name): ()  600x600+0+0  +1984+107
        1 child:
        0xc0026d (has no name): ()  600x600+0+0  +1984+107

  Absolute upper-left X:  1984
  Absolute upper-left Y:  107
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 600
  Height: 600
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1984+107  --664+107  --664-471  +1984-471
  -geometry 600x600+1984+85

  Bit gravity: ForgetGravity
  Window gravity: NorthWestGravity
  Backing-store hint: NotUseful
  Backing-planes to be preserved: 0xffffffff
  Backing pixel: 0
  Save-unders: No

  Someone wants these events:
      KeyPress
      KeyRelease
      EnterWindow
      LeaveWindow
      Exposure
      StructureNotify
      FocusChange
      PropertyChange
      ColormapChange
  Do not propagate these events:
  Override redirection?: No

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State
      Process id: (unknown) on host nanake.local

  Normal window size hints:
      Program supplied location: 1312, 31
      Program supplied size: 600 by 600
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined

  No window shape defined
  No border shape defined

---

Note -geometry 600x600+1984+85 and my display is 1920x1178.

Also note that the requested location should be fine:
      Program supplied location: 1312, 31
      Program supplied size: 600 by 600

If I try to do something similar with xeyes (xeyes -geometry 600x600+1312+31), the window is actually placed onscreen at '-geometry 600x600-8+31' with:

$ xwininfo -all -name xeyes

xwininfo: Window id: 0xe0000a "xeyes"

  Root window id: 0x141 (the root window) (has no name)
  Parent window id: 0x80001c (has no name)
     1 child:
     0xe0000b (has no name): ()  600x600+0+0  +1312+53

  Absolute upper-left X:  1312
  Absolute upper-left Y:  53
  Relative upper-left X:  0
  Relative upper-left Y:  22
  Width: 600
  Height: 600
  Depth: 24
  Visual: 0x22
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x21 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1312+53  -8+53  -8-525  +1312-525
  -geometry 600x600-8+31

  Bit gravity: NorthWestGravity
  Window gravity: NorthWestGravity
  Backing-store hint: NotUseful
  Backing-planes to be preserved: 0xffffffff
  Backing pixel: 0
  Save-unders: No

  Someone wants these events:
      StructureNotify
      PropertyChange
      ColormapChange
  Do not propagate these events:
  Override redirection?: No

  Window manager hints:
      Client accepts input or input focus: No
      Initial state is Normal State
      Process id: (unknown) on host nanake.local

  Normal window size hints:
      User supplied location: 1312, 31
      User supplied size: 600 by 600
      Program supplied window gravity: NorthWestGravity
  No zoom window size hints defined

  Window shape extents:  599x599+1+0
  No border shape defined

---

The main difference between the two is 'Bit Gravity State: ForgetGravity' ...

If I run adxv and then start quartz-wm, the window is dressed at the requested location.  If I then quit adxv and relaunch it, it is moved offscreen.  Looks like something in quartz-wm is going awry.

Please ignore comment #3. This was resolved by re-compiling
under OSX 10.11.

Yes, you see the problem - the "Adxv" window is not visible on
the screen. This was visible in OSX 10.10 and has
always worked under linux.

I don't modify the Bit Gravity State in my program.

It looks like we're sent a ConfigureRequest by the client to move it offscreen:

Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: <ConfigureRequest window:800016>
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: TRACE: id: 0xa0026b frame_id: 0x800016
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: Window 10486379l gravity: NorthWestGravity 1312,31 600x600 -> 1312,31 600x622
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: w1: 600 base: 0 min: 0 max: 0 inc: 0
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: h1: 600 base: 0 min: 0 max: 0 inc: 0
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: limit_window_size: 0 s: 1920x1178
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: w2: 600 base: 0 min: 0 max: 1920 inc: 0
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: h2: 600 base: 0 min: 0 max: 1156 inc: 0
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: r:(1312,31 600x622)
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: TRACE
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         win_rect: 1312,31 600x622
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         dock_rect: 1890,-22 30x1200
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         screen_rect: 0,0 1920x1178
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         screen_no_dock: 0,0 1890x1178
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         title_rect: 1312,31 600x22
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         title_int_rect: 1312,31 578x22
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         win_int_rect: 1312,31 578x622
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>:         ret: 1312,31 600x622
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: id: 0xa0026b frame_id: 0x800016 rect:(1312,31 600x622) force:0
Dec 30 16:00:17 nanake quartz-wm[2885] <Debug>: id: 0xa0026b frame_id: 0x800016 resized: 0 r:(1312,31 600x622) current_frame:(672,32 600x622)

Are you saying that adxv is sending the ConfigureRequest
to move itself offscreen?

No, ignore that last comment.  I was confused and was thinking that the 1312 was the offscreen location.  It isn't...

Ok, we're getting a ConfigureNotify event which is moving the window from (1312, 31) to (1984, 85).

Dec 30 16:33:35 nanake quartz-wm[8541] <Debug>: ConfigureNotify for window 0x61500000c100 at <(1312, 31) 600x622> <(1312, 31) 600x600> --> <(1984, 85) 600x622>

I see odd window jumping behavior in general.  I don't think this is a quartz-wm bug.  It looks like the app is sending ConfigureNotify events and moving the window offscreen.

I'm pretty sure that adxv isn't sending ConfigureNotify events to move
itself offscreen. If you have access to a system running OSX 10.10,
linux or cygwin, you can try setting the DISPLAY to set adxv to
display on one of those systems. I'll bet that will work correctly.

I've never seen odd window jumping behavior on any other system.
There's something different about the server or window manager than
on other systems.

I see the window jumping behavior using metacity and twm as well.  It just doesn't jump as far with those WMs.  Still looking to see if there is something on our end.

I see the window jumping behavior on Linux as well (used Fedora 22).

Created attachment 120741 [details]
windows jumping on fedora

If you can reduce the problem to something simpler, I'll take a look at it.  As it is, there is a ton of noise here, and it looks like the configuration requests are coming from the application itself.

For future reference, the branch I was using to debug ConfigureNotify events in quartz-wm is at https://github.com/XQuartz/quartz-wm/tree/DebugConfigureNotify

Perhaps you will find that useful in continuing triage on your end.

Adxv moves the windows to the same position on a screen,
regardless of the screen size. In the Fedora 22 video,
the behavior is correct. This is where the windows
should be. Here is the code I use to move the windows:

        Arg args[2];
        Screen *screen;
        int scr_width;

        screen = XtScreen(topLevelShell);
        scr_width = WidthOfScreen(screen);

        XtSetArg(args[0], XmNx, scr_width-608);
        XtSetArg(args[1], XmNy, 32-1);
        XtSetValues(imageWindow,args,2);

If I comment this out, then the windows are visible on the
screen, as placed by the window manager. It seems that the
user supplied window position hints are not being handled
correctly. The placement of these windows on other
systems is correct.

You're probably seeing a lot of ConfigureNotify events
since adxv has a bunch of windows which it sets
position hints for. I made a version where that's
all commented out, except for the image window:

http://www.scripps.edu/~arvai/adxv/adxv_1.9.10/adxv.test

This also prints a DEBUG line saying where it's
moving that window to.

That's not the correct way to do that.  You should place the windows at the expected locations initially.  Don't move them afterward mapping them in.

Would you mind providing a much reduced test case which doesn't create those other two windows and only does the minimal amount of calls to reproduce the issue?

Yes, moving the windows after creating them isn't the best way to do
it, but it should work, and has up until now always worked.  If this
isn't easy to fix, maybe I'll just do it that way.

This binary:

http://www.scripps.edu/~arvai/adxv/adxv_1.9.10/adxv.test

get's rid of all the window positioning except for the large image
window. I'll have to look at it some more to see if it's easy to keep
all the other windows from getting created and still have the program
run.

Thanks, yes, please try to provide a reduced test case (source is better than a binary as well) which only does the bare minimum to reproduce the issue.  The more reduced it is, the less noise there is that needs to be sifted through.  I already spent hours reading through logs yesterday trying to piece this together, so if you can help reduce that noise, it will be a big help.

FWIW, if I step through in a debugger, I don't see the issue, so it looks like possibly a race between adxv and quartz-wm.

*** Bug 94051 has been marked as a duplicate of this bug. ***