2009-07-17 14 views
0

私はその意味を広範囲に調査しました。私の推測では、何とかスタックが壊れているということです。 I取得tiny_free_list_add_ptrとは何ですか?

小さな_ free_ list_ ADD_ PTRという行の第16回の呼び出しで

NSDateFormatter *theFormatter = [[NSDateFormatter alloc] init]; 

問題の原因は何ですか?私はスタックが壊れていると思っていますか?

- (NSString *)formatDate:(NSString *)uglyDate withFormat:(NSString *)theFormat { 

    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
    NSDateFormatter *theFormatter = [[NSDateFormatter alloc] init]; 
    [theFormatter setDateFormat:theFormat]; 

    NSDate *realDateUgly = [NSDate dateWithNaturalLanguageString:uglyDate]; 
    if (realDateUgly == nil) 
     realDateUgly = [NSDate dateWithString:uglyDate]; 

    NSString *prettyDate = [[NSString alloc] initWithString:[theFormatter stringFromDate:realDateUgly]]; 

    [pool drain]; 
    [pool release];  
    [theFormatter release]; 
    return prettyDate; 

} 

答えて

2
  1. 私はあなたがここにプールを必要と疑います。
  2. あなたはプールを解放しています。 drainは非GCコードのreleaseと同じです。 (releaseはGCコードと同じように重複しています。なぜなら、それはノーオペレーションなのですから)
  3. prettyDateがリークしています。あなたはそれを自動リリースするはずです。 (そのプールを殺すために良い理由ですその周りプール、と動作しないこと、もちろん。)

あなたがMemory Management Programming Guide for Cocoaを確認し、メモリ管理の問題を修正したら、あなたは見つける必要がありますどちらか問題は修正されているか、少なくともそれをより正確に追跡することができます。

メモリ管理を修正しても問題が解決しない場合は、完全なスタックトレースを含めるように質問を編集してください。

+0

ご返信ありがとうございます。私はAutoreleaseセクションをすばやくすっきりとすべきではありませんでした。私はあなたの助言を取り、プールを取り除いた。きれいな日付については、私はこれに変更しました: NSString * prettyDate = [theFormatter stringFromDate:realDateUgly]; 問題はこの機能ではなくなりました。私はCocoaのメモリ管理プログラミングガイドを勉強しています。再度、感謝します。 –

+0

実際、もう1つ:私はまだtiny_free_list_add_ptrが何であるか知りたいです。ちょっと興味があるんだけど。 :) –

+0

おそらくmalloc機構内の内部関数です(空きリストと関係がある)。 –

0

あなたはtiny_free_list_add_ptrでクラッシュしていると思います。そうであれば、tiny_free_list_add_ptrはmalloc実装がヒープ上のメモリブロックを追跡するために使用する関数のように聞こえます。ヒープが破損している場合、私はこのような機能がクラッシュすると予想します。

ここで、または別の方法で、(ピーターが指摘した自動リリースプールのような)ものをリリースしている可能性があります。

環境変数NSZombiesEnabledを設定して実行してください。私は問題を賭けることをいとわないだろうhttp://developer.apple.com/technotes/tn2004/tn2124.html#SECFOUNDATION

0

がこれです参照:ドレイン、非GCアプリで

[pool drain]; 
[pool release]; 

リリースのように「振る舞い」。 'Behaves'はドキュメントで使用されている単語ですが、ドキュメントは、-drainが呼び出されたときに起こることを正確に正確に表現する必要がある場合、あいまいです。私にとって、少なくとも、「振る舞い」はちょっとした揺れの部屋を許します。特に「排水は放出とまったく同じです」と比較すると、解釈の余地がかなり少なくなります。

私がこれを引き起こす理由は、「ドレインが呼び出された後に自動解放プールにはどうなりますか?私はこの質問の文書で満足のいく答えを見つけることができませんでした。別の場所では、GCモードで実行すると、-drainはGCシステムのヒントとして動作し、objc_collect_if_needed()を呼び出します。 GCモードで実行しているときに、ドレンメッセージが送信された自動解放プールが「もう有効ではありません」(つまり、リリースメッセージが送信されたかのように動作する行に沿ったもの)という明示的なことは何も見つかりませんでした。ドキュメントで見つけられるものは、GCの下で実行されているときにインスタンス化されたNSAutoreleasePoolオブジェクトを複数回ドローイングすることを明示的に禁じているようです。

NSAutoreleasePoolクラスのドキュメントのトップには、最も近いものがありました。「プールを排水すると最終的にそれを解放する効果があります。しかし、ここで私たちを助けることはほとんどありません。これが行われたコンテキストは、これがGCモードまたは非GCモードに適用されるかどうかについてはっきりとしていません。いずれにしても、それはペダンティック辞書の定義では「今ではないが最終的に」という意味で「最終的に」認定されている。 '最終的に'の資格がなければ、インスタンス化された自動解放プールオブジェクトの割り当てが解除されたかどうかが明確でなく、誘導によって追加のメッセージをそのポインタに送ると未定義の動作になります。

私はこれをバックアップする権限がないことを指摘できないので、非GCモードでは、-drainは「リリース」と同じように振る舞います。 )。これが当てはまる場合は、NSAutoreleasePoolオブジェクトを「公開しました」ことがあります。この場合、2つのステートメントのいずれかをコメントアウトすると、問題はなくなります。

+0

非常に徹底的。私はすきです。 –

関連する問題