いつも使わせてもらってます。 Win7 32bit でver2.3.2.0 Unicode版を使っていますが、 たまに落ちるので、デバッグ版をコンパイルして 再現するまで起動／終了を繰り返しました。 すると、必ず sakura_core/util/shell.cpp 内119行の SHGetSpecialFolderLocation() で失敗します。 どうやら正しく解放できていないかと思われますが 他の方は、いかがでしょうか？おま環なのかもしれません。 ちなみにこの関数はもうサポートされないそうで いずれは SHGetFolderLocation() に代わらないといけないようですが https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb762203(v=vs.85).aspx ANSIとコードが共有ならば DllGetVersion() で判定するしかないですかね？。 https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb776779(v=vs.85).aspx
▼ hagiさん > ... > > ANSIとコードが共有ならば DllGetVersion() で判定するしかないですかね？。 > > ... こーどは きょうゆう して おりま せん
> こーどは きょうゆう して おりま せん ↓ http://svn.code.sf.net/p/sakura-editor/code/sakura/trunk ↑-これ とは
こんばんは。 ▼ hagiさん > すると、必ず > > sakura_core/util/shell.cpp 内119行の > SHGetSpecialFolderLocation() > > で失敗します。 64bit版windowsで試した限り再現しませんでした。 具体的にどうなって落ちる（デバッグブレークする）かまで書いていただけると、 より意味のあるレスを返すことができるような気がします。たぶん。 単に想像ですが、メモリ解放周りのコードがおかしい気がします。 CRTでいうところの「ヒープが壊れています。」的なエラーがでて止まったのでは？ そして、同ファイル内112行目の変数型が怪しいな、と。 https://msdn.microsoft.com/ja-jp/library/windows/desktop/bb762190(v=vs.85).aspx In its place, programs can call the equivalent (and easier to use) CoTaskMemAlloc and CoTaskMemFree. 121行目の呼出し結果によらず、 122行目で解放に行ってるあたり。 確保できてないのに解放したから 再確保しようとした瞬間に落ちる、と。 該当コードはv2専用なので windows2000で動作できる関数ならば使ってよい認識です。
▼ hagiさん > ちなみにこの関数はもうサポートされないそうで > いずれは SHGetFolderLocation() に代わらないといけないようですが https://sourceforge.net/p/sakura-editor/patchunicode/1107/ patch登録しました。
▼ noviceさん > ▼ hagiさん > > ちなみにこの関数はもうサポートされないそうで > > いずれは SHGetFolderLocation() に代わらないといけないようですが > > https://sourceforge.net/p/sakura-editor/patchunicode/1107/ > patch登録しました。 これって問題が解決した、ってことでいいんですか？ 32bit版のライセンスは持っていないから、 うちでは再現確認ができないので、 情報があればあげていただけるとありがたいです。