Can a System symbol spontaneously leak into a Global namespace?

Question

During the development of a program to process bioinformatic data, I have encountered a peculiar shadow warning:

GlobalParentList::shdw: Symbol ParentList appears in multiple contexts {Global,System}; definitions in context Global may shadow or be shadowed by other definitions. >>

Some background:

No where in the program do I create a variable named ParentList.
ParentList appears to be an undocumented System symbol (at least I can't find documentation on it.)
When I run my program as a complete, single block of code, I do not get the shadow warning, yet when I run segments of code linearly (which I am doing because I am writing a paper on the program), then the warning appears. This behavior is consistent whether I use Mathematica v 9.0.1 or 10.0.2
I have tracked the single line of code that generates the warning. Notice how the list of names in the Global context changes after the code is executed.

Before troublespot:

Names["Global`*"]

...,overlapadj,overlapcoord,passengermers,passengerpopup,...

Trouble spot & subsequent list of Global names:

Export[StringJoin[ToString[studyname], " - siRNA alignment.jpg"], 
  Pane[graphicoutput, 801], ImageResolution -> 300];

GlobalParentList::shdw: Symbol ParentList appears in multiple contexts {Global,System}; definitions in context Global may shadow or be shadowed by other definitions. >>

Names["Global`*"]

...,overlapadj,overlapcoord,Global`ParentList,passengermers,passengerpopup,...

Notice how the Global namespace has a new symbol called ParentList that wasn't there before the Export command.

Even though I do not get the shadow warning when I run the entire program as one block of code, I still do get the spurious creation of the variable ParentList in the Global context.
When I tried to recreate a minimal example of the bug in a new notebook I was not able to reproduce this behavior, making me think the primary issue really isn't with the Export command as shown above.

So, I am stuck.

A. Have you seen behavior like this before?

B. Would you have suggestions about how to troubleshoot this problem?

Edit (01/08/2015): Into the Heart of Darkness

Continued efforts to shed light on this peculiar behavior have failed. I have tried:

Re-positioning the offending line of code to another spot within the code (to see if execution order mattered) - shadow warning still appears
Re-typing the entire cell of code from scratch to see if the cell itself was corrupt - shadow warning still appears
Loading a copy of the notebook into Notepad and searched for the offending symbol. The symbol does not appear anywhere before the generation of the warning itself.
Changed the export format from jpg to gif - shadow warning still appears
Using various permutations of Trace to shake the problem loose - all to no effect. (I admit I am not very skilled at using Trace.)

It really seems as though Mathematica is spontaneously doing something that I am unable to monitor. Exasperating to say the least.

(01/08/2015) Later in the day

For some reason, I was inspired to try changing the export format from jpg to pdf, and the shadow warning disappeared. I have repeated this several times with a fresh kernel to be sure the change in behavior is real and reproducible.

Question C: Could there be a subtle "bug" in Mathematica's use of code for raster graphics vs vector graphics that causes the ParentList symbol to bleed into the global namespace?

(01/17/15) The Saga Continues ...

I sent a minimal example notebook to WRI and they were not able to reproduce the problem on their computers. They advised me to reset the system preferences by holding (CTRL-SHIFT) while loading Mathematica. Unfortunately this had no effect, as I still get the warning message.

Here is an example of the warning and new symbol that shows up in the global namespace:

enter image description here

If anyone is still interested, I have made the notebook I sent to WRI (and which causes the warning on my system) available here:

https://www.dropbox.com/s/ogspeip2ctmbahu/shadow%20testing-minimal1.nb?dl=0

I would be appreciative if others could run it (from a fresh kernel) and let me know if any warning appears. If not, I suppose I just have a corruption somewhere on my machine that I will have to live with. Certainly has me scratching my head. Thanks for reading.

(01/18/15) A peek at the solution...

StackExchange user Simon Woods found the symbol generating the shadow warning (ParentList) in the stylesheet being used to write the program. (See comment section below.) This stylesheet is the authoring template used by The Mathematica Journal.

While Simon was able to reproduce this bug (thankfully!) under Windows 7, StackExchange user ybeltukov was not able to reproduce the bug under the Linux version of Mathematica.

So, it seems that I stumbled upon a problem in a stylesheet that produces a shadow warning that is operating system dependent.

Question D: Why would a stylesheet function differently under different operating systems?

Question E: Has anyone seen a stylesheet behave this way under different operating systems?

I will alert WRI technical support about this and the editors of The Mathematica Journal.

Re: A – I have seen behavior like this, yes. Mathematica is a complex piece of software and some hard to detect bugs like this can often come up even in internal code. Re: B — As you say, it's hard to produce a minimal example for bugs like this (understandable), but it also makes it hard for us to try and troubleshoot. The question then becomes: Is this affecting your work? If so, how? That would give us a concrete path to proceed. If not, then I would suggest ignoring it or silencing it. — rm -rf, Jan 03 '15 at 23:25
To give an example, see this discussion between me, Leonid and Rojo. In the end, the mistake was mine — I hadn't fully isolated all my private symbols and a few of them happened to get exposed only in some very specific order of internal function calls. The point I'm trying to make is that this bug (albeit minor) crept into a smallish but non-trivial package that had extensive unit-tests and was identified only a year later. It is very likely that there are hundreds if not thousands of these in the Mathematica code base. — rm -rf, Jan 03 '15 at 23:36
It is quite likely that there is an evaluation-order bug here. Essentially, some part of the code is evaluating the symbol ParentList before the internal package that contains its definition is loaded (automatically). Unless this is directly affecting your work, I would suggest just ignoring it. — Stefan R, Jan 06 '15 at 21:04
@rm-rf. I appreciate your stating that you have seen unusual behavior like this as I really question my sanity sometimes when trying to debug code. The shadow warning is not altering my work, per se - that is, I still get the correct results. However, since I am looking to publish this program, I would rather not have to silence a warning and not be able to explain why I need to do that. I hope this doesn't prevent me from publishing. Please see edits above if you are still interested. — Todd Allen, Jan 08 '15 at 22:01
@rm-rf. The discussion you reference seems to focus on packages, and that is the darn thing about my program. I am not using any packages, and I never define the symbol "ParentList" anywhere, yet Mathematica seems to bleed it from the System namespace to the Global namespace. See 01/08/2015 edits above. — Todd Allen, Jan 08 '15 at 22:03
@Stefan R. Where could the ParentList symbol be coming from since I never define it? Do you know any information on what the Symbol context of ParentList is? What does Mathematica use it for? Please see 01/08/2015 edits above. — Todd Allen, Jan 08 '15 at 22:06
I am not able to replicate this oddity. What are graphicoutput and studyname? — Daniel Lichtblau, Jan 08 '15 at 23:13
@DanielLichtblau. is a variable to hold user input for calling their experiment something, such as "insulin gene". has Column for its Head, but it is just a picture of RNA sequences mapped to a gene. I don't really expect anyone to solve this without seeing the entire program, but as I hope you can understand, I am reticent to publish everything here as I would like to professionally publish this in the future. Do you think it is worth sending to technical support at WRI if I can generate a "minimal" example of the behavior? — Todd Allen, Jan 09 '15 at 02:09
Definitely worth sending to technical support. Also if you can come up with a smallish example using nonproprietary input, it might be useful to post here because it seems some readers have experience with similar issues. That said, it could well end up as something that requires in-house expertise. — Daniel Lichtblau, Jan 09 '15 at 15:57
From what I can tell ParentList should be either in System or BoxForm contexts. From your comments and edits I think this isn't actually affecting the outcome of the computations and commands you're performing? It's just giving an annoying message? — Stefan R, Jan 09 '15 at 22:58
@Daniel L. and @ Stefan R. I have just sent a minimal example to WRI technical support. The tracking number is -CASE:2211879 if either of you are curious enough to take a look. I appreciate your following this thread. Thank you. — Todd Allen, Jan 10 '15 at 00:48
@Stefan R. You are correct. The program produces correct output. My primary concern about the shadow warning is that I can't explain it, and don't want that to interfere with potential future publication of the program. — Todd Allen, Jan 10 '15 at 00:49
I can reproduce the error with Mathematica 10.0.2 on Windows 7. It appears that the embedded stylesheet contains $CellContext`ParentList as a spurious entry in the InputAutoReplacements list for the style cells StandardForm and TraditionalForm in the FormatType Styles section. Removing these makes the problem go away, as does changing the stylesheet to something else. — Simon Woods, Jan 18 '15 at 11:27
@ybeltukox and Simon Woods. Thank you for taking time out of your day to run my code and provide invaluable feedback. Both of you made statements that are beginning to clarify the situation. — Todd Allen, Jan 19 '15 at 01:28
@Simon Woods. Again, thank you. Your comment has brought me back from the brink of insanity. I would like to encourage you to add your comment above as an answer to this question, because it is the first piece of information that has shed light on the problem. I am adding another edit to my post, and would welcome any thoughts you may have, as new questions arise from your information. Finally, what made you think to look in the stylesheet for this suspicious symbol? — Todd Allen, Jan 19 '15 at 01:30
I confirm also the error with v.10.0.2 (OS X 10.9.5). When I run your example notebook - with the Mathematica Journal style - I have also 2 additional warning errors just printed after the ParentList::shdw: message : AbsoluteOptions::optx : Unknown option WindowSize in [shadow testing-minimal1.nb] and FilterRules::rep : ReturnPacket[$Failed] is not a valid replacement rule. BUT if I copy/paste all your code in a new notebook with default stylesheet, I get no warning message at all. — SquareOne, Jan 19 '15 at 10:26

score 6 · Accepted Answer · answered Jan 19 '15 at 11:32

I can reproduce the error with Mathematica 10.0.2 on Windows 7. In fact it is sufficient to open the example notebook and evaluate Rasterize[test] in a new input cell:

enter image description here

It appears that problem is due to the embedded stylesheet, which contains $CellContext`ParentList as an entry in the InputAutoReplacements list for the style cells StandardForm and TraditionalForm in the FormatType Styles section. Removing this symbol makes the problem go away, as does changing the stylesheet to something else.

(Note: I found this by simply opening the notebook in a text editor and searching for ParentList)

I did a bit of googling to try to understand what $CellContext`ParentList could be:

According to John Fultz here, "ParentList represents the (input autoreplacements) which have been inherited from the notebook level". I think the idea is that you can have some autoreplacements which are global and some which are specific to a certain cell style.

Another John Fultz post here states that "$CellContext is a symbolic placeholder in cell expressions (most typically Dynamic expressions inside of Cells) which indicates that the ambient context as defined by the CellContext option should be used" and also "You'll see it a lot in cell expressions, but it's supposed to be replaced with the actual context whenever an operation goes to the kernel."

So I wonder if the error appears because at some point during rasterization $CellContext resolves to System`, and then later on to Global`. We know that rasterization uses a Front End process, so that would perhaps explain the different results for different operating systems.

Clearly this is not a full explanation of the problem, but I think it sheds some light on the situation. The Mathematica Journal may appreciate an email letting them know of this problem with their stylesheet.

If @JohnFultz is around, he may be able to explain what is going on.

Can a System symbol spontaneously leak into a Global namespace?

Question C: Could there be a subtle "bug" in Mathematica's use of code for raster graphics vs vector graphics that causes the ParentList symbol to bleed into the global namespace?

1 Answers1