Bill,

When you say "when JANE  goes to TEST to open the DIV - it just disappears", I assume that what you are saying is that JANE can run the pathfinder interface but can not run the xyview.
What you might want to try is open up a terminal window and cd to the division in question and then just issue a 'xyview' command.
Maybe this will show an error message and give you a clue on what is going wrong. 

Otherwise your shortest route to success might be to open up a support ticket with SDL support.

Good luck!

When she used xyview on the DIV - she received an "Segmentation Error - Core Dump"

I looked at the DIVs job.log and it looks like the composition completed.

Where does the Core Dump go - I checked the /tmp folder and the XPP temp folder /xyenterprise/xpp/workspace/tmp

And what happens if JANE tries to edit a spec file? Does that work or is it just the xyview that fails?

It seems to be tied to our images - she can open a DIV without an image but when she opens one with a IMAGE it crashes - is there a DIV size constraint

So, I'm going to comment on a bunch of stuff all at once.

By default the xyview (and sdedit) programs do not output anything to stdout/stderr (these streams are effectively redirected to /dev/null if you know what that means in UNIX-land).

If you do want to see if running either of these programs produces any messages on stdout/stderr, then you must run the programs from the command-line and add the -cons option (meaning enable "console" messages). I think it unlikely that will tell you anything as to why the xyview program is dying, but it's possible it could give you something meaningful so it might be worth a try.

A core dump is typically written to the CWD of the program when it dumps core; for the xyview that would be the DIV folder.

However, on (modern) Linux systems the saving of a core dump to disk is typically disabled (even if it says "core dump" when the program died).

There are system-side and user-level "limit" settings for this. I don't know what SHELL you use, but for CSH the commands to see the limit settings are 'limit -h' to see all of the "hard" (system-wide) limits and 'limit' to see the user-level (or "soft") settings and for BASH the commands are 'ulimit -aH' to see the "hard" limits and 'ulimit -a' to see the user-level settings. There are a number of limit settings. The relevant one to core dumps for 'limit' is "coredumpsize" (or "core file size" for 'ulimit'). The "hard" limit is typically "unlimited" and the user-level setting is typically "0" (meaning you will not get any core dump file).

You can change the limit and get a core dump file, however since you'll not have the source code and corresponding debugging environment the core dump file will not do you any good. Unfortunately, core dump files are also not transferable to another system (like to SDL support or R&D) - there's too much of the specific O/S embedded in them for them to be read on another system for the information they contain. And that essentially is why the coredumpsize limit is typically set to 0 by default, so that you don't populate your file system with useless (and sometimes large) core dump files. That's also a reason why it is pretty much necessary that we at SDL be able to reproduce a "segmentation violation" problem in-house before we can begin to figure out what kind of bug or problem is involved.

Now, Bill (and everyone), when you describe such a problem as a program like the xyview dying it's very important that you be more specific. At first you said that when the user just opened the DIV, the xyview just died (aka disappears). But then later you said that the job.log file seemed to indicate that composition completed. I found myself thinking: Which is it? Dies just on opening, or dies after composition (or both)? You last said that it appears to be image related, so I'm guessing that your conclusion is that opening a DIV to a page with an image is what is causing the xyview to die.

I'm guessing that you don't know that the xyview (and compose) program actually writes to a file named job.worklog while in progress, until a session is saved/stored (or compose program completes successfully), in which case the job.worklog file is then renamed (or rewritten) as a file named job.log. So, when the xyview is crashing it would be the job.worklog file that you should be looking at to see if it contains any useful information (and the job.log file is an "old" file from the last time that a successful compose/xyview was run and therefore not relevant).

And to get to the actual problem itself, if the user is only having this problem on TEST and not on DEV or PROD then there must be something different between the systems (aka environments). Perhaps some hotfix on TEST that's not on DEV/PROD, or some hotfix missing on TEST. Or something else (e.g. with images) that's different.

I am going to echo Bart's suggestion to open a support ticket.  

I'm not sure exactly what you mean by a "DIV size constraint"?

There is a "Max Page Size" setting in the JT, but the contents of an image (other than the coding to reference it) doesn't take up any of that allocated page buffer memory. And an overflow of the Max Page Size would result in a "Page Buffer Overflow" error - a "controlled" fatal error that then causes the xyview to exit after the error is acknowledged, but not a "segmentation violation - core dump" (dying/crashing) type of error.

Problem solved - the IM cache path was not defined for this particular new GRP = /graphics/viewcache/.xycache

Not sure why some users could open Articles with images and only one user was having the problem.

But at least the problem was solved - by removing the View Path for the LIbrary Name alogos. in im config.

Thanks for all the help - that was a interesting problem.

That was indeed interesting especially the solution...
Thanks for the follow-up 

Definitely a mis-configuration, but the 'xyview' should not "crash" in this case. Minimally, it should give some sort of user error warning message. You should open a support ticket with the description and possibly job that it takes to make the xyview "core dump" when the view path for an image library points to an undefined directory. I'm glad you were able to figure out what was wrong.