Hata ayıklama bilgileriyle yayın yapılarını "tam" veya "yalnızca pdb" olarak mı derlemeliyim?

114

Bir C # projesi için Visual Studio 2010'da, Proje Özellikleri> Oluştur> Gelişmiş> Hata Ayıklama Bilgileri'ne giderseniz üç seçeneğiniz vardır: yok, tam veya yalnızca pdb. Bu sorunun cevabına dayanarak, tam ve yalnızca pdb arasındaki bazı farkları anladığıma inanıyorum. Bununla birlikte, hangisi bir sürüm derlemesi için daha uygundur? "Tam" kullanırsam performans sonuçları olur mu? "Yalnızca pdb" kullanırsam üretim sorunlarında hata ayıklamak daha zor olur mu?

"Full" ve "pdbonly" arasındaki fark nedir? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

— RationalGeek
kaynak

Yalnızca pdb veya hiçbiri, her zaman sürüm derlemeleri içindir.

— leppie

13

@leppie Teşekkürler ama bu pozisyon için bazı gerekçeler arıyorum.

— RationalGeek

İlgili soru: stackoverflow.com/questions/1270986/…

— janv8000

Performans etkisi yoksa bu harika. Peki ya hafıza etkisi? Bir StackTrace örneği oluşturur ve dosya bilgisi talep edersem, bunun pdb sembol verilerinden gelmesi gerekir. Uygulama başladığında tüm semboller belleğe yüklenmiş mi? Bunun yaklaşık hafıza kullanımı nedir? (ör. kod boyutuna göre genel gider yüzdesi.)

— yoyo

90

İle inşa ederdim pdb-only. Yayınlanan ürüne bir hata ayıklayıcı ekleyemezsiniz, ancak bir kilitlenme dökümü alırsanız, çökme sırasında yığın izlerini ve bellek dökümlerini incelemek için Visual Studio veya WinDBG'yi kullanabilirsiniz.

Bunun fullyerine ile devam ederseniz pdb-only, aynı faydaları elde edersiniz, ancak yürütülebilir dosyanın doğrudan bir hata ayıklayıcıya eklenebilmesi dışında. Ürününüz ve müşterileriniz göz önüne alındığında bunun makul olup olmadığını belirlemeniz gerekir.

PDB dosyalarını bir yere kaydettiğinizden emin olun, böylece bir çökme raporu geldiğinde bunlara başvurabilirsiniz. Bu hata ayıklama sembollerini saklamak için bir sembol sunucusu kurabilirseniz , çok daha iyi.

İle inşa etmeyi noneseçerseniz, sahada bir çökme olduğunda hiçbir başvurunuz olmayacak. Kaza ile ilgili herhangi bir gerçek sonrası inceleme yapamayacaksınız, bu da sorunu bulma yeteneğinizi ciddi şekilde engelleyebilir.

Performans hakkında bir not:

Hem John Robbins hem de Eric Lippert/debug bayrakla ilgili blog yazıları yazdı ve ikisi de bu ayarın performans üzerinde sıfır etkisi olduğunu gösteriyor . /optimizeDerleyicinin optimizasyon yapıp yapmayacağını belirleyen ayrı bir bayrak vardır.

— Matt Dillard
kaynak

7

@Matt, / debug anahtarındaki MSDN makalesi , 'tam' ayarı kullanmanın performans üzerindeki etkisi konusunda açıkça uyarıyor:

If you use /debug:full, be aware that there is some impact on the speed and size of JIT optimized code and a small impact on code quality with /debug:full. We recommend /debug:pdbonly or no PDB for generating release code.

— Allon Guralnek

3

@Matt: "Tam" ın "yalnızca pdb" ye kıyasla hiçbir dezavantajı yoksa, ancak yalnızca avantajları varsa, neden "yalnızca pdb" var? Onu 'tam' kullanmak için herhangi bir sebep var mı? Ayrıca, düzeltmeyi 'Topluluk İçeriği' bölümündeki MSDN makalesine eklemelisiniz.

— Allon Guralnek

9

@AllonGuralnek bağlantılı John Robbins makalesinden alıntı: Gerçek neden: tarih. .NET 1.0'da farklılıklar vardı, ancak .NET 2.0'da yok. Görünüşe göre .NET 4.0 aynı kalıbı izleyecek. CLR Hata Ayıklama Ekibi ile iki kez kontrol ettikten sonra, hiçbir fark yoktur.

— bentayloruk

5

Bu doğru değil. Yalnızca pdb ile derleyebilir ve yine de bir hata ayıklayıcı ekleyebilirsiniz. Sadece emin olmak için yaptım.

— Mark

2

"Yalnızca pdb ile derlerim. Yayınlanan ürüne bir hata ayıklayıcı ekleyemezsiniz" Buradaki bilgi kaynağınız nedir? Hem @ Mark hem de belirttiğim gibi, bu doğru görünmüyor.

— MEMark

66

UYARI / hata ayıklama anahtarı için MSDN dokümantasyonu (Visual Studio'da Hata Ayıklama Bilgisidir) güncel değil gibi görünüyor! Yanlış olan şey bu

/ Debug: full kullanırsanız , JIT ile optimize edilmiş kodun hızı ve boyutu üzerinde bir miktar etkisi olduğunu ve / debug: full ile kod kalitesi üzerinde küçük bir etkisi olduğunu unutmayın . Sürüm kodu oluşturmak için / debug: pdbonly öneririz veya PDB yok.

/ Debug: pdbonly ve / debug: full arasındaki bir fark, / debug: full ile derleyicinin DebuggableAttribute, JIT derleyicisine hata ayıklama bilgilerinin mevcut olduğunu söylemek için kullanılan a yaymasıdır .

O zaman şimdi doğru olan nedir?

Yalnızca Pdb - .NET 2.0'dan önce, piyasaya sürülen üründen (müşteri makineleri) çökme dökümlerinin araştırılmasına yardımcı oluyordu. Ancak hata ayıklayıcının eklenmesine izin vermedi. Bu, .NET 2.0'daki durum değildir. Öyle tam olarak aynı Dolu .
Tam - Bu, kilitlenme dökümlerini araştırmamıza yardımcı olur ve ayrıca derlemeyi yayınlamak için hata ayıklayıcı eklememize olanak tanır. Ancak MSDN'nin bahsettiğinin aksine, performansı etkilemez (.NET 2.0'dan beri). Yalnızca Pdb ile tamamen aynıdır .

Tam olarak aynıysa, neden bu seçeneklere sahibiz? John Robbins (Windows hata ayıklama tanrısı) bunların tarihsel nedenlerle orada olduklarını keşfetti .

.NET 1.0'da farklılıklar vardı, ancak .NET 2.0'da yok. Görünüşe göre .NET 4.0 aynı kalıbı izleyecek. CLR Hata Ayıklama Ekibi ile iki kez kontrol ettikten sonra, hiçbir fark yoktur.

JITter'in bir hata ayıklama derlemesi yapıp yapmadığını kontrol eden şey / optimize anahtarıdır. <...>

Sonuç olarak, sürüm yapılarınızı / optimize + ve / debug anahtarlarından herhangi biri ile oluşturmak istemenizdir, böylece kaynak koduyla hata ayıklayabilirsiniz.

sonra bunu kanıtlamaya devam ediyor.

Artık optimizasyon ayrı bir anahtarın parçasıdır /optimize(visual studio'da buna denir Optimize code).

Kısacası, DebugInfo ayarının yalnızca pdb-only veya full olmasına bakılmaksızın, aynı sonuçları alacağız. Öneri önlemek için Yok yayımlandıktan ürün veya takılarak ayıklananları kazasında döker analiz edememek mahrum olacağından.

— rpattabi
kaynak

3

Harika cevap! Kendi araştırmalarım (oluşturulan dosyaları karşılaştırarak) aynı sonuçları gösteriyor.

— MEMark

@rpattabi pdbonly ve full'un aynı olduğu referansı belirtebilir misiniz? Yıl 2019 ve belgeler hala farklı olduklarını ve tam performanslarının düşeceğini gösteriyor. Ve VS2019, Releaseyapılandırmanın hata ayıklama türü varsayılan olarak pdbonly.

— joe

@joe MSDN belgelerinin altında bir tartışma var msdn.microsoft.com/en-us/library/8cw0bt21.aspx . Ona bir göz atın. Bir katılımcı , pdbonly ve full'den aynı şekilde bahsedildiği güncel bilgiler için github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… adresini işaret etti . (Bilginize. Artık Windows veya VS kullanmıyorum. Bu yüzden orada olanları takip etmiyorum. Ancak gözden

— geçirdiğim gibi, cevabımdaki

16

Yalnızca PDB'yi isteyeceksiniz, ancak PDB dosyalarını kullanıcılara vermek istemeyeceksiniz. İkili dosyalarınızın yanı sıra bunlara kendiniz için sahip olmak, size WinDbg gibi bir hata ayıklayıcıya çökme dökümlerini yükleme ve programınızın gerçekte nerede başarısız olduğunu görme yeteneği sağlar. Bu, kodunuz erişiminizin olmadığı bir makinede çöktüğünde oldukça yararlı olabilir.

Tam hata ayıklama, kodunuza [Hata ayıklanabilir] özelliğini ekler. Bunun hız üzerinde çok büyük bir etkisi var. Örneğin, tek adımlamayı kolaylaştırmak için bazı döngü optimizasyonları devre dışı bırakılabilir. Ek olarak, izlemeyi açtığı için JIT süreci üzerinde küçük bir etkiye sahiptir.

— blowdart
kaynak

Mantıklı. Yine de DLL'leri kullanıcılara gerçekten dağıtmıyorum - bu bir ASP.NET uygulaması. Ancak cevabınızı geliştirebilir ve neden "yalnızca pdb-yalnızca" ile "tam" arasında gitmeniz gerektiğini gerekçelendirebilir misiniz? Bu bir performans sorunu mu?

— RationalGeek

@jkohlhepp: Bazı bilgileri kaybedeceğiniz için (JIT nedeniyle) hata ayıklama sürüm yapılarının biraz zor olduğunu da eklemek isterim. Hemen hemen her zaman, yöntem bağımsız değişkenlerinin değerlerini göremezsiniz. Bu sorunu çözmek için geçici olarak devre dışı JIT optimizasyon kullanarak yapabilirsiniz bu .

— Ilian Pinzon

Blowdart'a teşekkürler ve ek bilgi için Ilian Pinzon'a teşekkürler. Yayın koduyla mükemmel hata ayıklama yapamayacağınızı biliyorum, ancak PDB'lere sahip olmak hiç yoktan iyidir.

— RationalGeek

"Tam" ayarını kullanarak yok değil bir performans etkisi vardır. Basitçe bir hata ayıklayıcının çalışan bir sürece eklenmesine izin verir.

— Matt Dillard

1

MSDN Matt, msdn.microsoft.com/en-us/library/8cw0bt21 hakkında güzel soru , yanıtı bekliyorum.

— Luke Hutton

4

İşlenmemiş bir istisna işleyicisi yazma sürecindeyim ve yığın izleme yalnızca pdb kullanıldığında satır numarasını içerir, aksi takdirde Yok'u seçtiğimde yalnızca Alt / İşlevin adını alırım.

.Pdb'yi dağıtmazsam, yalnızca pdb yapısında bile yığın izlemedeki satır numarasını alamıyorum.

Bu yüzden, pdb'yi VB uygulamamdaki exe ile birlikte dağıtıyorum (bir LAN'da XCOPY dağıtımı).

— rheitzman
kaynak