bugDenemo - Bugs: bug #30450, Bugs

 
 

bug #30450: Bugs

Submitter:  None
Submitted:  Wed 14 Jul 2010 11:16:33 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  rshann
Originator Name:  Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 15 Aug 2010 08:40:05 AM UTC, comment #22: 

My box uses acrord32.exe as default viewer without trouble, so we'll assume it is a gremlin in your system. Everything else is sound, though it is debatable whether specifying "open" is better than passing NULL, the docs quoted really give no indication. I'll revert that.

Richard Shann <rshann>
Group administrator
Sun 15 Aug 2010 01:21:09 AM UTC, comment #21: 

0.8.19f didn't fix the use of the default pdf viewer when windows default viewer set to AcroRd32.  (No problem when windows default set to another viewer)  I guess might as well just leave it alone as it could have little to do with denemo and no one else can reproduce this bug.-DW

Anonymous
Sat 14 Aug 2010 10:00:05 PM UTC, comment #20: 

Schnooks.  Forget everything I said about this.  I changed my default pdf viewer and it's all good now.
I remembered Richard saying that Print Preview did not work at all for him on windows (July 15) and I assumed that was still true until I just found out from Nils that it was no longer the case.
Been my system all along.
Should have tried this long ago.  Might as well revert the change to using "open" although it seems that everything works fine with it set to that--chat, help all open Firefox with no problem whether it's running or not already.
I guess it can't hurt to uninitialize with CoUninitialize, either, but sorry to send you guys on that wild goose chase.
I wonder if it was AcroRd32 or some windows registry problem.  Oh well.
-Dan W.

Anonymous
Sat 14 Aug 2010 06:35:32 PM UTC, comment #19: 

I am afraid it is a long shot, since the docs explicitly say you can call CoInidialiseEx multiple times with the same args, and the closing is just for "grace", it can't affect something that should have already happened. I think it is worth making only one call to the init.
A closing call would be made when closing the program, which couldn't help.
What is the behavior of your Chat to Other Users menu item? Do you need the browser open.
What is the behavior of your Help menu item - that also uses file assoc?

Thanks for persisting. I have tested version e, and it is the same on my Vista box.

Richard Shann <rshann>
Group administrator
Sat 14 Aug 2010 05:40:45 PM UTC, comment #18: 

As suspected, the "open" thing didn't fix anything:Just tested Nils' new 0.8.18e on windows and the print preview still works every other time when the pdf viewer field is left blank. 

If the stuff I wrote about CoInitializeEx sounds plausible perhaps we could give that a try soon too.  Just for a quick test could just put a call to CoUninitialize() at the end of the code for the windows part of run_file_association in utils.c, and see if that solves anything; if so maybe it would be better to have separate funcs that initialize/uninitialize only once.

Sorry to not be able to try these things out on my own.  Maybe someday I'll get around to that.
-Dan W.

Anonymous
Sat 14 Aug 2010 01:00:18 PM UTC, comment #17: 

I read the code in print.c, function open_viewer as: It uses run_file_association when the length of the viewer field for the relevant type(pdf or png) is 0.  When this condition is not satisfied, i.e., when the relevant field is non-empty, it uses g_spawn_async. 
It does seem like a long shot that the default verb changing would be the cause.
...
I was just scrutinizing the run_file_association and it occurred to me that maybe the CoInitializeEx needed to be closed.  And browsing the documentation I found this. 

http://msdn.microsoft.com/en-us/library/ms886306.aspx

CoInitializeEx must be called at least once, and is usually called only once, for each thread that uses the COM library. Multiple calls to CoInitializeEx  by the same thread are allowed as long as they pass the same concurrency flag, but subsequent valid calls return S_FALSE. To close the COM library gracefully on a thread, each successful call to CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.


void CoUninitialize();
A thread must call CoUninitialize once for each successful call it has made to CoInitializeEx. Only the CoUninitialize call corresponding to the CoInitializeEx call that initialized the library can close it.

...
If I'm wrong about this I'll stop bothering you with conjectures.  But this seems to be a possible explanation for the problem: every time we call run_file_association it is making another call to CoInitializeEx, and it is never uninitialized.  It sounds like it would be better to have a separate function that (on windows) calls CoInitializeEx when denemo starts or at the first call to run_file_association and another one that calls CoUninitialize.  -DW

Anonymous
Sat 14 Aug 2010 10:02:57 AM UTC, comment #16: 

I have put "open" in as the verb for you to try. I'll also try it on a windows Vista system I have available; it will be interesting to see how/if it affects the Chat action. It is a slender hope though, as I can't imagine what other verb would be preferred as a default.
BTW it is not too clear from your comments that you have read the print.c code to mean "always use file assoc on windows".

My reading of the code is that it never does the g_spawn... on windows for displaying a lilypond-generated file. That was my intention I am sure. It should perform ShellExecute on the .png or .pdf file. (Always assuming the pref is blank, otherwise it does g_spawn_xxx with the preferred executable).

Richard Shann <rshann>
Group administrator
Sat 14 Aug 2010 12:15:57 AM UTC, comment #15: 

In print.c the function open_viewer does rather different things depending on whether the pdf viewer is set or not--if it's set, it uses g_spawn_async- and as I posted earlier in this thread, that way works as long as you specify the path without quotes.
If the viewer string is not set, it uses run_file_association.  As far as I can tell this is the only difference that could be causing the one way (viewer specified) to work and the other way (not specified) to not work. 
[And the answer to the concern I had in my earlier post as to whether the idea of specifying the verb to "open" might cause problems when the viewer is set, appears to not be a problem.]

I don't see anything that could go wrong in run_file_association other than that the "verb" is left up to the decision of windows rather than specified.  Setting it (the second param) to "open" can't in any way I see harm anything (unless this command is used to do other things like run an .exe?) and it just might resolve this issue.  Maybe to be safe,  make it a new parameter to the function run_file_association (in utils.c) with default value of NULL, and have the call from print.c set it to "open". 
Does this seem plausible?
-DW

Anonymous
Fri 13 Aug 2010 11:23:47 PM UTC, comment #14: 

My guess is that the call to ShellExecute is not quite going as expected. 
from utils.c:
  g_print("Running ShellExecute %s\n", filename);
  CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
  return ShellExecute(NULL, NULL, filename, NULL, NULL, 0) > 32/* value above 32 indicating success */;

http://msdn.microsoft.com/en-us/library/bb762153%28VS.85%29.aspx

I don't understand everything here but it might be worth trying setting the second parameter (the "verb") explicitly to "open", as the explanation for what actually happens when you set it to NULL is, to me, obtuse(quote from above site):
*
NULL

    In systems prior to Windows 2000, the default verb is used if it is valid and available in the registry. If not, the "open" verb is used.

    In Windows 2000 and later, the default verb is used if available. If not, the "open" verb is used. If neither verb is available, the system uses the first verb listed in the registry.
*
I hope this is on the right track, but you would know better if it's worth a shot.  I'm assuming this function in utils.c is only used when the Externals->pdf viewer is blank; otherwise this suggested change might cause problems.
-DW

Anonymous
Fri 13 Aug 2010 04:27:12 PM UTC, comment #13: 

I figured out how to get Print Preview to work every time on my copy of denemo 0.8.19d on windows xp.  It seems to be a problem with ... something having to do with the path, apparently.

Anyway, if I put the exact full path to AcroRd32.exe in the Externals->pdf viewer, WITHOUT quotes, it works!  (Quotes normally required in command line due to the spaces in C:\Documents and Settings\...)

I.e., I changed Externals->pdf viewer to
C:\Program Files\Adobe\Acrobat 7.0\Reader\AcroRd32.exe

If I put quotes around it, it doesn't work.
This "fix" seems too easy to have been missed for so long.  I guess part of why I didn't find it sooner is I assumed AcroRd32 was in the path for the dos box--in fact it IS in the "path" for the little command line you get when you go to start->run.  So even though running simply AcroRd32.exe from the little command line "run" box works, it does not work in the dos box environment (it's not in the path) and that must be why it doesn't work setting just AcroRd32.exe in the pdf viewer field.

I have no idea why it doesn't work when the pdf viewer field is left blank.  If I do the most trivial modification to that blank configuration by setting the pdf viewer to a minimal batch file that merely does
%1
which is to say, just calls the .pdf that would have been called anyway...it works.

So in summary, to get it to work, set the pdf viewer field in externals to be the full path of your viewer without quotes.  Or do as I just described and save a super-trivial batch file consisting of merely %1 and put that thing's full path in the viewer field.  Of course it would be nice to know why it doesn't work by default with the field left blank.
-Dan W.

Anonymous
Thu 12 Aug 2010 09:17:14 PM UTC, comment #12: 

I presume double clicking a .pdf file does launch something successfully? That is what the ShellExecute thing is supposed to be doing.
The call is

ShellExecute(NULL, NULL, filename, NULL, NULL, 0)

where filename is the thing printed in the message. This is in utils.c
What happens if you create a different file assoc for .pdf?
You can do this temporarily. E.g. I have launched another copy of denemo.exe to see that the file assoc is launched by setting it in the properties to that .exe

Richard Shann <rshann>
Group administrator
Thu 12 Aug 2010 06:38:02 PM UTC, comment #11: 

The error that I wrote in my August 11 post, only came when I tried changing the lilypond path to that quoted expression.  Normally running the Print Preview doesn't give that error.  In fact it doesn't give any errors at all in the console even when the pdf is not displayed (which is the case every other run of Print Preview).  All that appears in the console is
Running ShellExecute C:\....\denemoprint.pdf

That's part of why I don't believe it's a failure to run lilypond; the other part is that lilypond does in fact run, and produces a .ps some of the time, the other times it updates the .pdf.
-DW

Anonymous
Wed 11 Aug 2010 02:57:41 PM UTC, comment #10: 

the launching of the pdf reader is done (on windows) by
 file association - that is the same mechanism as when you double click a pdf file.
I noticed that the Help->Chat to other users
option no longer launched my browser (in windows), it works if I have launched the browser already (or, even, if I go on and click Help->Browse Manual, where it opens a tab in the browser launched).
Perhaps having acrord32.exe already running may work. Otherwise some pdf displayer that is able to refresh itself off a file (in which case there would be no need to launch a pdf viewer at all - the viewer would need to not hog the file though, which windows apps generally do).
The message quoted is a failure to run the lilypond executable, not a failure to launch the viewer. The viewer would fail with
      g_warning("Could not run the file association for a %s file\n", is_png?".png":".pdf");
I am not sure what (invalid argument) means in the Failed to execute child process. It is a message returned by the
  g_spawn_async_with_pipes (locatedotdenemo (), /* dir */
call in print.c
Would it help to print out what the arguments are to this call before it happens?


Richard Shann <rshann>
Group administrator
Wed 11 Aug 2010 11:47:28 AM UTC, comment #9: 

If I try to put
"c:\Program Files\Denemo\usr\bin\lilypond.exe"
in the Externals, (which is correct enough to call lilypond from the windows command line), I get an error:

denemo-console.exe 3348
Warning: Error launching lilypond is Failed to execute child process (invalid argument)

and no results.  I don't think the problem is calling lilypond because that much actually works, every time.  It's the pdf viewer that doesn't work 50% of the time.  Even though my theory as to why this problem occurred (involving ghostscript) was wrong, the observations I made earlier in this thread should be still applicable--apparently there is a half-dead AcroRd32 process half of the time (might be worthwhile to try with a different reader).  See earlier posts if you want the details.
(I was wrong about 0.8.18c not working at all with lilypond, that was due to bad installation.)
-DW

Anonymous
Tue 10 Aug 2010 02:28:48 PM UTC, comment #8: 

what happens if you put the full path c:\ etc to the lilypond.exe
in the externals?

Richard Shann <rshann>
Group administrator
Tue 10 Aug 2010 11:35:48 AM UTC, comment #7: 

No, I sent an email to Nils.  I tried all of the denemo commands (print preview, print view refresh) that invoke lilypond and none work.  Trying to print preview a simple score does not work.  Running denemo-console gives this error:
denemo-console.exe:2728 ....Failed to execute child process (No such file or directory)
Lilypond 's binary  is in the usr\bin directory along with denemo, so not sure why it would claim no such file.
-Dan

Anonymous
Tue 10 Aug 2010 10:18:45 AM UTC, comment #6: 

is this fixed in 0.8.19c?

Richard Shann <rshann>
Group administrator
Fri 30 Jul 2010 01:02:06 AM UTC, comment #5: 

My big idea on ghostscript seems to have been wrong because I checked what happened when I delayed denemo's issuing the command to open the pdf until well after gs finished making the pdf.  Results were unchanged.  So I'm out of ideas on that.

Going back to the CLI, it works well now on 0.8.19a for windows.  Will be very handy to have.-DW

Anonymous
Thu 29 Jul 2010 04:54:46 PM UTC, comment #4: 

This is a long post, but my theory and recommendations are at the bottom, and you can just skip to those and see if it makes sense.  Follows are my observations of this bug where print preview works only every other run on windows.

1.RUN PRINT PREVIEW WITH NO denemoprint.* files in .denemo directory:
Lilypond produces denemoprint.ps invokes Ghostscript to convert to .pdf (which it does successfully) and deletes the .ps.  The command to display the file in pdf viewer is executed when lilypond is done, and (using the Adobe reader) an AcroRd32 process is created which is using the denemoprint.pdf; however, it is unseen except when you look at process list, and no pdf is displayed.  (If you try to delete the pdf, you're told AcroRd32 is using it.)
NET RESULTS: denemo prints:.pdf, log file, .ly
invisible AcroRd32 process using the denemoprint.pdf

2.RUN WITH THE ABOVE RESULTS (i.e., with the lurking AcroRd32 process and the .pdf file in .denemo):
On these runs, lilypond produces a .ps but doesn't delete it, it does not even try to invoke ghostscript, and the pdf reader finally appears visible, showing you the .pdf you created at a previous run of Print Preview.  Net result: denemoprint.pdf file is untouched on these runs, and is finally displayed in the external pdf viewer; denemoprint.ps is generated and left alone to exist (until lilypond overwrites and then deletes it next run).

3.RUN WITH RESULTS FROM 1, BUT AFTER KILLING AcroRd32:
Same results as 1 above--so the difference is the lurking AcroRd32.

Note: If I run AcroRd32 at a command line when it's in that latent/lurking state, it shows the desired denemo print.

My guess at what's going on:
When there's no lurking pdf viewer process, I think lilypond invokes gs, terminates and gives denemo the impression that all is done, and denemo invokes the pdf viewer--but that gs is still processing the ps to make the pdf, giving the pdf viewer no chance to load it when it's launched and leading to weird behavior (lurking process).
In the case of 2, where the pdf viewer is already running (unknown to the user) and holds the rights to the denemoprint.pdf, lilypond sees that the would-be output file is already being used, so it can't overwrite it and it doesn't bother to run ghostscript.  Lilypond terminates, denemo invokes the pdf viewer, which is already running anyway and it shows the file it's been holding the rights to all along, denemoprint.pdf.
So basically, denemo doesn't know that gs is still running.

My guess at how to fix it:
If gs is indeed still running when denemo gets the signal from lilypond that it's done processing, then the only thing needed to do would be to have denemo wait until gs is done-maybe invoking it itself instead of leaving that to lilypond.
-Dan W.

Anonymous
Mon 26 Jul 2010 04:11:55 PM UTC, comment #3: 

CLI crash should now be fixed (in git). Will have to await another gub build for windows to be sure.

Richard Shann <rshann>
Group administrator
Thu 15 Jul 2010 11:34:49 PM UTC, comment #2: 

2.I don't think #2 was due to having the file open elsewhere, because I could overwrite it with a non-blank file.  I.e., when the scheme window is totally empty, it doesn't overwrite the old.  When the scheme window is not totally empty, it does overwrite.  Easy workaround to blank it out is to just put a #f for the scheme and save it.  That works.

3.My hunch was this this was because denemo was trying to open the pdf file while it was being generated, but that doesn't seem to be the case, looking at the console window--the command only appears after lilypond's done.I do notice that it doesn't work at all when I try to put something reasonable in Externals->pdf viewer.  When this field is blank it works every other time.

-Dan

Anonymous
Thu 15 Jul 2010 04:51:53 PM UTC, comment #1: 

1) I can confirm - on windows denemo just dies if you use the CLI button. I have no debug route for this:(
2) I have done this ok on windows, it will be windows file locking thing - did you still have a text editor open on the file when you tried to save?
3) Print preview did not work at all for me on windows. I am not sure whether the code needs updating in the way that the regular printing was for windows. (We had to create a .bat file to run lilypond with an extra parameter, -dgui).

Richard Shann <rshann>
Group administrator
Wed 14 Jul 2010 11:16:33 PM UTC, original submission:  

Using 0.8.19 windows version,
1.Using the CLI in the scheme window crashes denemo immediately.
(Just opening the scheme window, and hitting enter inside the CLI is enough to crash)

2.Failed to overwrite/delete old menu initialization script when I tried to save a blank file over it.
To see if this bugs your copy, save a simple init script to the score menu, such as #f.  Now, empty out the scheme window, and try to blank out the init script by saving this empty window.  Test to see if it worked--in my case, it still shows the old init script, #f.

3.Print preview does nothing every other run.  Seems like when you execute it, it actually shows you the generated lilypond from LAST run, or nothing.
-DW

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rshann (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-08-15 rshann Open/ClosedOpen Closed
    2010-08-15 rshann StatusNeed Info Fixed
    2010-08-10 rshann StatusNone Need Info
        Assigned toNone rshann

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code