I am not working or compiling scide so forgive my ignorance:
Does mScProcess->stopLanguage(); quit server also?

void Main::quit() {
    mSessionManager->saveSession();
    storeSettings();
    mScProcess->stopLanguage();
    QApplication::quit();
}

For me it doesn't happen on OS X, but on Ubuntu 15.04/Qt5.21 and Windows too

I cant find the code quiting the server from the ide exit.
Where is it?

It seems sclang closes open servers automatically on exit. At least that's what happens in OS X if I quit sclang running in a terminal. Maybe sclang isn't unloaded properly on Windows and Linux? I vaguely remember some error-reports in that direction...

Yes, I just tried on Ubuntu:

Exiting sclang (Ctrl-D)
sc3> main: waiting for input thread to join...
main: quittting...
/quit sent

LID: event loop stopped
empty
cleaning up OSC
terminate called without an active exception
Aborted (core dumped)

On Windows this cannot be tested because the readline interface doesn't work.

@bagong Same here (archlinux)

The same here, Debian 64bit, scide compiled against Qt 5.3.2, not sure what commit is causing this, but it is quite recent commit (two week or so), I am rebuilding master branch quite often nowadays.

Haha, if it were Windows I'd try to identify it ;) Maybe someone else? If it's really only 2 weeks old you'd only need 4 or so builds. But my feeling is the reports on this are quite a bit older...

It is quite recent behaviour.. I was looking into recent history, recompiled few times, and it seems to me the bug happens after this merge: 0f5abf4.

Great find! maybe @sonoro1234 has an idea. And maybe his PR #1445 helps here? Could you try?

Hah, it's gone with the PR. Interestingly sclang still borks on close. But the server is shut down. So two apparently unrelated issues, haha.

I tried this on Ubuntu only, can't do it on Windows atm.
Maybe this will raise the motivation to test the PR ;)

pull request #1318
was composed by three commits. The first two take care about portaudio minimum buffer size. The third one was the first one of a series that completes with #1445.
It is there because my ignorance about git was not understood:
In this message I tried to explain what had happened in

http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/pull-request-td7618195.html

but the response was to merge

Best solution could be to apply #1445 to finish the work (or revert third commit of this merge if this dont solves the issue)

Is the sclang issue also related to pull request #1318?

There was already this issue 10 day before the merge
#1438

The first email is from the 21st of March, not related to your commit:
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/0-exit-quot-aborts-quot-instead-of-exiting-td7617119.html

Does PR #1445 helps with sclang problem?

No ;)
#1456 (comment)

So, what shall we do?

My feeling is merge #1445 as quickly as possible, but have one or two guru's have an eye on it. Or do you want to create a separate PR for that commit? It's possible...

Will fixing the supernova crash on OS X take a long time?

I added a commit in #1445 for that.
What do you mean with a separate PR?

I retract that remark ;)
Btw, what's that first commit in #1445? Is that how you updated your master branch?

yes

The proper way is to pull master from github sc repo and then push it to your own repo. This is a monster commit. It probably boils down to nothing when merged into master, but this is really intransparent. So I assume you can only interact with your own sc-repo when working with git locally, right?

yes, I made local file modifications, commit and push

I am not sure how to compare that commit with sc-master. Some diffing would be required. The way you are working, the relation between the sc github repo and your sc repo will get more and more intransparent and messy.
You need to add the sc github repo as remote and make sure your own stuff doesn't get mixed.
For now the cleanest way would probably be this:

• add scgithub as remote
• fetch scgithub
• create a local branch that tracks scgithub master
• create a new branch that goes off that branch tracking scgithub master
• cherry pick into that new branch what you effectively have in allow plugins unload in supernova also #1445

What does that pull-request #1 refer to?

I did a pull request in my fork with "compare forks"
sonoro1234/supercollider@master...supercollider:master
It was my number 1 pull request then I merged and pulled from local drive

Thanks for all your help

You're welcome!

I have made the gitjub changes and PR #1465
hope it is ok

Great man, thanks for your dedication!

Good job guys, thanks for developing Supercollider!

see #1467. Please test! Works for me with Ubuntu...

Well, I am sorry, I cannot confirm bugfix in my case, 87e26cd tested.. then:

s.reboot

still gives me:

Exception in World_OpenUDP: bind: Address already in use
deinitialize plugins
ERROR: server failed to start

It seems some zombies are still walking around (even after proper ScIde shutdown), my specs now are:

CMake (3.0.2)
gcc version 4.9.2 (Debian 4.9.2-16)
QT (5.3.2)
Linux *** 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3 (2015-04-23) x86_64 GNU/Linux

Thank you for testing! There is a line in your description I wonder about:

Well, I am sorry, I cannot confirm bugfix in my case, 87e26cd tested

As you found out, the commit you are referring to is the one that introduced the bug. Rather than just reverting that commit, @sonoro1234 is still trying to enhance plugins unload.
Did you apply pull request #1467? It does fix the issue for me, but it has not been applied to master yet. So in order to test the changes, you need to merge pr #1467. Your commit history should look something like this after merging:

40ca0722e28ec875ddbb181fe095c78e722ba4ae Merge remote-tracking branch 'scgithub/pr/1467' into testPU
21c661bad3bd01281bb6aac3dd9c3222a334a15f Merge pull request #1470 from sonoro1234/supernova_v_to_V
36ac0ac489d8b20c7c76341265ee3e3c34efbdee supernova: print version with -v and use -V for verbose
a0a1e924b3d54158217929e13ee6e567397892ce sclang: help prQuitInProcessServer with default false
f942d6749275c8a6893a842af6ab1e53c68ee305 scsynth: hide as public API function deinitialize_library
c37c5d5c925263945ae6f5e5e0ea0695ed8da87b Merge pull request #1469 from jamshark70/topic/WritingClassHelp
57385e2763f0350743f1c9fbbc39ce4f84835d07 Help: WritingClasses: Extension methods are like obj-c categories, not protocols
306c417b238a26d50ad8f12daac9c112ed1eb705 plugins/DiskIO_UGens: allow plugin unload
4cacbe4ae9a64806ea4402eba2dab68327460de3 supernova: complete unload plugins
dd76c6948c0a9271605c84448fe3da30b4497b29 scsynth: complete unloading plugins
e8525d378f4c4793c31f38caab4561ea080702df fix JITGui use of color scheme, so it can be changed.
f31b799b15cfaa3411f77372a89b566bec806970 help: comparison of Pan2 and PanAz

There are various ways how to test pull requests. The one I like most is described at the end of the sc git cheatsheet:

https://github.com/supercollider/supercollider.github.io/blob/master/development/git-cheat-sheet.md

Oops you're right.. my deep appologize.

#1467 merged, compiled, the bug still presist.

Exception in World_OpenUDP: bind: Address already in use
 deinitialize plugins

I may also make some mistake during the merge, as it can't be done automagically, so I have done it by hand.

You mean you needed to fix merge conflicts? That likely means you didn't use latest vanilla master as merge base. @sonoro and I have been applying this repeatedly and never had a merge conflict. So maybe check your master? Possibly you have merged something else that conflicts? Or more likely: you didn't update master to the latest (git pull while on master)? And make sure to get the latest version of the PR, an additional commit was made 6 hours ago. You might have to pull and then remerge the pr/1467 branch.
You might also like to try an alternative solution to the server-hang: PR #1472, but this one attempts a more comprehensive solution ;)
Thanks a lot, man, for trying this. We really need testers!

Yes, there were conflict during merge, is there any vanilla master? I thought I am on latest master branch by default..

Maybe you haven't synchronized it with master for some time? Or did you merge anything else into it?

Hm probably not, I should be up to date..

latest master cloned
.git config adjusted to fetch orgin/pr/*
git fetch made
#1467 merged
conflicts appeared
(git pull gives Already up-to-date.)

Am I doing something wrong?

The problem is I cannot reproduce this, which means if done properly there shouldn't be merge conflicts... To detect a mistake I'd have to see the commands you used. If you didn't get a "cannot resolve origin/pr/1467" error, the problem can only be the state of your master.
From a sentence you formulated earlier I conclude that you believe commits are changed later in order to fix mistakes. But that is not the case, all commits stay the way they are. Fixes are applied on top of the old commits. So anything you have in master is still there and will not be changed retroactively.

As you seem to have tried to merge pr/1467 into master it seems likely that you have some old stuff in there as well. It's not good practice to merge anything into master. You should create a dedicated branch off master first, and merge into that branch. Am I guessing into the right direction?

Ok, trying to figure out..

wget https://gist.githubusercontent.com/K0F/91823a6e5fd198506342/raw/723a03b23e2d29ade5ad3796ebe78ac7bf8c4b21/reproduceMerge.sh && chmod a+x ./reproduceMerge.sh && ./reproduceMerge.sh

src:
https://gist.github.com/K0F/91823a6e5fd198506342

So you are running this as a bash-script? I am not sure if you get error-messages from earlier lines in that case. I am also not sure about depth one and that stuff, for me the easiest has always been to say --recursive, which brings in the submodules automatically, so no need to do submodule init/update. But that's just a side remark. Generally I would also question why you recreate the repo each time? But anyways, it should work.

I am pretty sure the mistake occurs after you added the pr/* line to your git-config. After that you have to do

git fetch origin

otherwise the pr's you want to merge won't be there (adding the line to the config file only creates a reference, nothing is downloaded). And then, I also don't see where you merged the branch. When would the manual merging you talked about have happened?

so the missing steps are (after your sed line):

git fetch origin // all prs should now arrive
git merge origin/pr/1467 // this will merge into whichever branch you are atm

And apart from that better practice would be something like:

git fetch origin
git checkout -b testPU
git merge origin/pr/1456

and then continue with the creation of build folder etc:

BTW: if you still see

deinitialize plugins
unloading plugin

in the post-window after s.quit, that means the PR has not been applied.

Wait, now I seem to see something else in the gist than I saw before... ;) Did you change it, or did I have halucinations? :) Maybe we should communicate some other way. These threads are posted to everybody following the SC repo...

Yes, sorry for spamming whole community..
#supercollider @ irc.freenode.net?

what's your name?

Ok, big thanks to @bagong for support. I can reproduce bugfix #1467. Server reboots and quits nicely now, thanks a lot.

Thanks for staying on the ball and testing, Krystof!

Can we close?

No, J., the issue is still open. "Cannot reproduce" is Mac only. The fix is one of #1467 or #1472. Both work, but somebody has to decide which one is right for the time being...

The issue can be closed, to, right? @gusano

@bagong Yes. Thanks!