opening a file from file manager when audacity is open gives error message

Opening a second file from a file manager when audacity is already open gives
some stupid error about not being able to open two instances.
Should instead open a new window as would happen if using File -> Open

This bug was initial reported on Ubuntu: https://launchpad.net/bugs/615307

To clarify, this is only a problem with right-click > Open with. Dragging in a
second file does import (into the same project) as on Windows.

I think this summarises the current problems:

* If Audacity is already running, using the command line or context menu to
open further files fails with "Audacity is already running"

* Even if Audacity is not already running, selecting multiple files to open
from a context menu will only open one of the files; the others will give
"Audacity is already running"

These are not issues on Windows. Can anyone comment on Mac behaviour?

(In reply to comment #2)
> Can anyone comment on Mac behaviour?

Bill tested and there is no problem on Mac.

This is because (thanks to Leyland) both Windows and Mac are special-cased to
enable the second copy of Audacity to open an IPC path to the first and pass on
the command line argument. The first (main) copy then executes the load and the
second one quits.

Any volunteers to write an equivalent set of functionality for Linux (may be
see how Gimp does this on Linux for inspiration?)

Created an attachment (id=497)
Tobias Platen's patch to allow passing subsequent files to Audacity on Linux

Tested on Win and Mac that patch builds and does not affect current
functionality.

Tested on Ubuntu 13.10 dragging audio files to Audacity icon, using file
manager Open (with association set to the format), file manager Open with, and
importing files at command-line using "audacity file1.wav file2.wav".

Works well in preventing "Audacity is already running". Big improvement.

Multiple files are still a problem. With the patch, multiple files can be now
be imported with all the above methods if Audacity is not running. But if
Audacity is already running, only one of the multiple files will import (no
error appears). This isn't a Linux limitation as e.g. Gedit and LibreOffice
open multiple files when already running. Also Audacity on Windows and Mac does
not have this limitation.

The patch looks good to me with just one minor change: The socket file
shouldn't be placed in "/tmp/audacity.sock", but in "/var/run/audacity.sock"
instead.

(In reply to comment #6)

Not my bailiwick, but I think Benjamin's comment means it's not patch_ready.

(In reply to comment #6)
Benjamin wrote:
> The patch looks good to me with just one minor change: The socket file
> shouldn't be placed in "/tmp/audacity.sock", but in "/var/run/audacity.sock"
> instead.
Can you explain more? Is it to preserve the file between reboots?

Will every Linux distro have /var/run/? "Yann Le Doaré" claimed recently on -devel that Linux "AlbatrOS" did not have /var/tmp/.

(In reply to comment #8)
> Can you explain more? Is it to preserve the file between reboots?

/var/run is the right place to store socket files according to the current Filesystem Hierarchy Standard:
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
It is also recommended by others: http://stackoverflow.com/questions/7580346/where-to-place-unix-domain-af-unix-sockets-end-points-files

But after testing the patch, I discovered that /var/run is not writable by non-root. So this won't work for Audacity which is launched by any user.

The socket file won't be preserved between reboots. Only data in /var/tmp would be preserved.

> Will every Linux distro have /var/run/? "Yann Le Doaré" claimed recently
> on -devel that Linux "AlbatrOS" did not have /var/tmp/.

Every Linux distro should have /var/run (at least if they want to comply with the FHS).

I tested the patch on Ubuntu 14.04, but the running audacity process crashes when a second audacity process is launched:

Backtrace:
#0 0x00007ffff6d883c9 in GSocketGUIFunctionsTableConcrete::Uninstall_Callback(GSocket*, GSocketEvent) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#1 0x00007ffff69a50e1 in GSocket::Read(char*, int) () from /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0
#2 0x00007ffff69a167a in wxSocketBase::_Read(void*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0
#3 0x00007ffff69a1714 in wxSocketBase::Read(void*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0
#4 0x00007ffff69a057d in wxSocketInputStream::OnSysRead(void*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0
#5 0x00007ffff66db267 in wxInputStream::Read(void*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#6 0x00007ffff699fa78 in wxTCPEventHandler::Client_OnRequest(wxSocketEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu_net-2.8.so.0
#7 0x00007ffff6711966 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#8 0x00007ffff6711a0b in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#9 0x00007ffff6711d77 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#10 0x00007ffff67118c8 in wxEvtHandler::ProcessPendingEvents() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#11 0x00007ffff668f161 in wxAppConsole::ProcessPendingEvents() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#12 0x00007ffff6df8d4e in wxAppBase::ProcessIdle() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#13 0x00007ffff6d73db1 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#14 0x00007ffff19d0ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff19d1048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff19d130a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff22be447 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#18 0x00007ffff6d8728a in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#19 0x00007ffff6df8b4c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#20 0x00007ffff66bee5d in wxEntry(int&, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#21 0x00000000004febd2 in main (argc=1, argv=<optimized out>) at AudacityApp.cpp:647

> I tested the patch on Ubuntu 14.04, but the running audacity process crashes
> when a second audacity process is launched
Hi Benjamin,

I can't reproduce that on Ubuntu 14.04 in a release build of Audacity. Did you patch a debug build? What are the exact steps by which you opened a second process? I tried from the command-line and some "Open with" with audio files.

And did you modify the patch to use /var/run instead, if so were you root?
I can't see the value of using a path for the sockets file that requires root. That is probably why var/run was not chosen.

Also I was surprised my self-built Audacity on 14.04 has no file associations (not even AUP). Moreover I can't use Nautilus Properties (in Unity Shell) to add Audacity associations for MP3, WAV etc. because my local install of Audacity isn't listed. I had to install Ubuntu-Tweak to set an association. Is that a bug in Ubuntu or Audacity? I don't have that problem in Ubuntu 13.10.

(In reply to comment #11)
As there has been no response from Benjamin about how to reproduce the crash and given using "/tmp/audacity.sock" appears to be the most practical solution, I suggest we apply this patch as is so we can get more testing on it.

Moved back to patch_ready.

Just committed the fix for this. It was based on Tobias's patch, but his patch didn't properly exclude wxMac.

And Benjamin was correct, there was a crash when the "running" Audacity attempted to disconnect the socket. Took me nearly all day to figure out what the heck was going on.

Basically, the IPCConn object was being deleted before the the actual command was received.

And Tobias had put the socket into /tmp, but it needed to go into Audacity's temp directory as selected by the user. That way it follows the lock file. If left in /tmp, it would be possible for one user to open an audio file in another users Audacity.

It definitely wouldn't hurt to validate both Linux AND Windows since they now share the same code.

(In reply to comment #13)
Leland's modified patch committed at r13692.

(In reply to comment #13)
Leland wrote:
> It definitely wouldn't hurt to validate both Linux AND Windows since they
> now share the same code.
On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching HEAD), using Explorer "Open with" to open an AUP file or to import an associated file type displays a Windows dialogue "Audacity... has stopped working".

Problem signature:
  Problem Event Name: BEX
  Application Name: audacity.exe
  Application Version: 2.1.0.0
  Application Timestamp: 549176af
  Fault Module Name: StackHash_0a9e
  Fault Module Version: 0.0.0.0
  Fault Module Timestamp: 00000000
  Exception Offset: 11f87555
  Exception Code: c0000005
  Exception Data: 00000008
  OS Version: 6.1.7601.2.1.0.256.1
  Locale ID: 2057
  Additional Information 1: 0a9e
  Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
  Additional Information 3: 0a9e
  Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Clicking the options in the dialogue to "close the program" does not close it and the project or file appear to function normally.

If after HEAD is running I execute 2.0.6 or a build made on the 2nd December in some way (e.g. by executing an AUP file still associated with 2.0.6), ten empty cascading project windows appear followed by "Audacity is already running" which stops the addition of new windows.

(In reply to comment #15)
> (In reply to comment #13)
> Leland wrote:
> > It definitely wouldn't hurt to validate both Linux AND Windows since they
> > now share the same code.
> On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching HEAD),
> using Explorer "Open with" to open an AUP file or to import an associated file
> type displays a Windows dialogue "Audacity... has stopped working".
>

I can't make this happen Gale. Can you try again?

Leland

I tried the current svn head on Ubuntu 14.10 with wxgtk 3.0 (./configure --disable-dynamic-loading && make) and ran these commands in the build tree:

./audacity testfile.ogg
./audacity testfile.flac

When I run the second command, the second audacity sends a signal to the first audacity and crashes on exit. The first audacity shows this assertion (and does not open the second file):

/usr/include/wx-3.0/wx/ipcbase.h(136): assert "Assert failure" failed in OnExec(): This method shouldn't be called, if it is, it probably means that you didn't update your old code overriding OnExecute() to use the new parameter types ("const void *" instead of "wxChar *" and "size_t" instead of "int"), you must do it or your code wouldn't be executed at all!

(In reply to comment #17)
> I tried the current svn head on Ubuntu 14.10 with wxgtk 3.0 (./configure
> --disable-dynamic-loading && make) and ran these commands in the build tree:
>
> ./audacity testfile.ogg
> ./audacity testfile.flac
>
> When I run the second command, the second audacity sends a signal to the first
> audacity and crashes on exit. The first audacity shows this assertion (and does
> not open the second file):
>
> /usr/include/wx-3.0/wx/ipcbase.h(136): assert "Assert failure" failed in
> OnExec(): This method shouldn't be called, if it is, it probably means that you
> didn't update your old code overriding OnExecute() to use the new parameter
> types ("const void *" instead of "wxChar *" and "size_t" instead of "int"), you
> must do it or your code wouldn't be executed at all!

HOWDY BENJAMIN!!! LONG TIME! :-)

Okay, I'll take a look and thanks.

Leland

(In reply to comment #17)
> I tried the current svn head on Ubuntu 14.10 with wxgtk 3.0 (./configure
> --disable-dynamic-loading && make) and ran these commands in the build tree:
>
> ./audacity testfile.ogg
> ./audacity testfile.flac
>
> When I run the second command, the second audacity sends a signal to the first
> audacity and crashes on exit. The first audacity shows this assertion (and does
> not open the second file):
>
> /usr/include/wx-3.0/wx/ipcbase.h(136): assert "Assert failure" failed in
> OnExec(): This method shouldn't be called, if it is, it probably means that you
> didn't update your old code overriding OnExecute() to use the new parameter
> types ("const void *" instead of "wxChar *" and "size_t" instead of "int"), you
> must do it or your code wouldn't be executed at all!

Both (unrelated) issues have been correct in r13854 and r13855.

Leland

(In reply to comment #19)
> Both (unrelated) issues have been correct in r13854 and r13855.

Confirmed. Both work now, but I found a not-working corner case. When you launch a second audacity without specifying a file, another assertion is triggered:

$ ./audacity testfile.ogg
$ ./audacity

/usr/include/wx-3.0/wx/arrstr.h(178): assert "nIndex < m_nCount" failed in Item(): wxArrayString: index out of bounds

(In reply to comment #20)
> (In reply to comment #19)
> > Both (unrelated) issues have been correct in r13854 and r13855.
>
> Confirmed. Both work now, but I found a not-working corner case. When you
> launch a second audacity without specifying a file, another assertion is
> triggered:
>
> $ ./audacity testfile.ogg
> $ ./audacity
>
> /usr/include/wx-3.0/wx/arrstr.h(178): assert "nIndex < m_nCount" failed in
> Item(): wxArrayString: index out of bounds

This one should be fixed in r13856.

(In reply to comment #16)
>>> (In reply to comment #13)
>>> Leland wrote:
>> It definitely wouldn't hurt to validate both Linux AND Windows since they
>>> now share the same code.
>> On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching HEAD),
>> using Explorer "Open with" to open an AUP file or to import an associated file
>> type displays a Windows dialogue "Audacity... has stopped working".
>>
> I can't make this happen Gale. Can you try again?
It's still 100% repeatable for me in current alpha build http://gaclrecords.org.uk/win-nightly/download.php?fname=./audacity-win-r13863-2.1.0-alpha-06-jan-15.zip .
It also happens if I simply execute the same Audacity again.

Gale wrote in comment 13:
> If after HEAD is running I execute 2.0.6 or a build made on the 2nd December
> in some way (e.g. by executing an AUP file still associated with 2.0.6),
> ten empty cascading project windows appear followed by "Audacity is already
> running" which stops the addition of new windows.
Still 100% repeatable for me.

(In reply to comment #5)
Gale wrote:
> Multiple files are still a problem. With the patch, multiple files can be now
> be imported with all the above methods if Audacity is not running. But if
> Audacity is already running, only one of the multiple files will import (no
> error appears). This isn't a Linux limitation as e.g. Gedit and LibreOffice
> open multiple files when already running. Also Audacity on Windows and Mac does
> not have this limitation.
Still 100% repeatable for me on Ubuntu 13.10. Perhaps this should be a new P4 bug but it is not good that subsequent files that should be opened in separate windows are silently ignored. Let me know Leland if you want to put this issue to one side for now.

All else tests fine on Linux (but I never got the crashes Benjamin wrote of in release builds in the first place).

(In reply to comment #21)
> This one should be fixed in r13856.

Confirmed the fix (on Ubuntu 14.10 with wxgtk 3.0).

(In reply to comment #22)
> (In reply to comment #16)
> >>> (In reply to comment #13)
> >>> Leland wrote:
> >> It definitely wouldn't hurt to validate both Linux AND Windows since they
> >>> now share the same code.
> >> On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching HEAD),
> >> using Explorer "Open with" to open an AUP file or to import an associated file
> >> type displays a Windows dialogue "Audacity... has stopped working".
> >>
> > I can't make this happen Gale. Can you try again?
> It's still 100% repeatable for me in current alpha build
> http://gaclrecords.org.uk/win-nightly/download.php?fname=./audacity-win-r13863-2.1.0-alpha-06-jan-15.zip
> .
> It also happens if I simply execute the same Audacity again.
>
> Gale wrote in comment 13:
> > If after HEAD is running I execute 2.0.6 or a build made on the 2nd December
> > in some way (e.g. by executing an AUP file still associated with 2.0.6),
> > ten empty cascading project windows appear followed by "Audacity is already
> > running" which stops the addition of new windows.
> Still 100% repeatable for me.

I totally get this now. Sorry, I was being more dense than I normally am.

Fix forthcoming...

Fix committed in r13873

Testing on Mac El Capitan on 01a95c5-2.1.3-alpha-13-feb-16

and

Testing on W10 on audacity-win-r4d154c4-2.1.3-alpha-18-feb-16

I do not see this, subsequent projects open correctly. Looks ok on these two platforms but still reqires testing on Linux

Tested at 396a6f0 from audacity/audacity on Linux.
* Second windows opens fine,
* If audacity is run with no command line argument, nothing crashes.
so flagging this as Test-OK-Lin.

I tested opening further files as below which I think may not have been (fully) tested. I used HEAD "0ceae62".

Windows 10:
* "Open with" set up to open 2.0.6 when HEAD was already running (HEAD took the file, correctly)
* "Open with" set up to open HEAD when HEAD was already running
* "Send to" with multiple files selected
* Opening further audio files and projects from the command-line
* Just typing "audacity" from the command-line when two project windows were open (no crash).

Ubuntu 14.04:
* Launching Audacity from the command-line then opening further audio files and projects from the command-line
* Then selecting multiple files and using Nautilus "Open with" (which supports multiple files).

All worked well for me.