Vscode: تحطم عند الجري بين عشية وضحاها

يبدو أن هذا يحدث باستمرار كل ليلة أترك الكمبيوتر يعمل. يبدو أنه لا يستجيب بسبب تجاوز وحدة المعالجة المركزية إلى أقصى حد. ربما تكون بعض الحلقات اللانهائية في مكان ما ، ربما تتعلق باستقصاء الملف أو git repo؟

أتساءل عما إذا كان نظام التشغيل قد قرر وضع VSCode (Electron في الواقع) في حالة يتسبب فيها في هذا الانهيار. لقد تعرضت لضغوط من الإلكترون إذا كان لديهم دليل.

لم يحدث مطلقًا في Atom fyi ، على الأقل في 1.19.x (من الذاكرة) و 1.2.4.

لدي مشكلة مماثلة ، منذ تحديث نوفمبر (0.10.2 / 0.10.3؟). في كل يوم تقريبًا كنت أقوم بتسجيل الدخول للعثور على نوافذ VSCode المتروكة طوال الليل قد تعطلت جميعها (مع خطأ التعطل القياسي غير الإعلامي / الاعتذاري ، "تعطل Visual Studio Code").

اليوم ، بعد تحديث 0.10.5 ، تعرضت لأول تعطل أثناء وجودي هناك - لسوء الحظ ليس أثناء استخدامه بنشاط.

تشغيل VSCode على Windows 7 (64 بت) ، واستخدامه بشكل أساسي كمحرر JS في مشروع كبير جدًا - ما يقرب من مليون سطر إجمالي (بما في ذلك libs التي أحتاج إلى البحث عنها ، لذلك لا يتم استبعادها). لا توجد مشكلات في الأداء في الاستخدام العادي ولم ألاحظ أي استخدام مفرط للموارد يؤدي إلى تعطل اليوم.

يسعدني تقديم المزيد من سجلات / معلومات الأخطاء التفصيلية إذا تمكن شخص ما من توجيهي إليها.

أتلقى نفس المشكلة الأساسية مثل @ Elusive138 ، عندما أترك الشفرة تعمل طوال الليل (كل ليلة) ، في الصباح دون أن أفشل ، أحصل على "تعطل Visual Studio Code".

لا يزال يعبر عني على vscode 0.10.5 ، Ubuntu 12.04

حاولت إعادة الإنتاج على Windows 10 و Mac OS 10.11 و Ubuntu 15 دون حظ. أظن أن هناك مشكلة تتعلق بنفاد الذاكرة ولكن بالنسبة لأي مما سبق ، زادت الذاكرة كثيرًا.

هل يمكن لأي شخص محاولة إعادة إنتاج هذا بالشروط التالية:

• هل يتكاثر عند فتح مثيل فارغ فقط من التعليمات البرمجية (ملف | إغلاق المجلد)
• هل يتكاثر عند فتح مساحة عمل مع عدم فتح أي ملف في المحرر

Ubuntu 12.04 ، تعذر على vscode 0.10.5 إعادة إنتاج وتركه خلال عطلة نهاية الأسبوع بمثيل فارغ.

قد يكون هذا تسربًا دقيقًا للذاكرة ، وقد ظهر من خلال استخدام الذاكرة المرتفع نسبيًا على هذا النظام.

غادرت الكمبيوتر في حوالي الساعة 5:30 مساءً ، مع زحف ذاكرة النظام ببطء - كانت 15402 ميجابايت في الساعة 7:00 مساءً. في الساعة 3:09 صباحًا كان أقرب نهج إلى حد التزام النظام (17682 ميجابايت) ، وانخفض استخدام الالتزام من 16.218 ميجابايت إلى 15217 ميجابايت. أظن أن هذا قد يكون مكان تعطل VSCode. كان استخدام الالتزام مستقرًا هناك حتى توقف التسجيل حوالي الساعة 6 صباحًا (نفدت مساحة القرص - عدادات الأداء هذه كبيرة!).

لسوء الحظ ، لم أقم بتضمين جميع عمليات VSCode لذلك ليس لدي تسجيل خاص بالعملية. سأحاول أن هذه الليلة.

سيكون مفيدًا جدًا إذا تمكنت من الحصول على وقت الانهيار. هل يترك VSCode السجلات في أي مكان؟

لسوء الحظ ، لم أقم بتضمين جميع عمليات VSCode لذلك ليس لدي تسجيل خاص بالعملية. سأحاول أن هذه الليلة.

سيكون ذلك مفيدًا للغاية ، شكرًا!

حاليا vscode لا يسجل على القرص.

@ Elusive138 هل يمكنك مشاركة مساحة العمل التي تسمح بتشغيل vscode عليها؟

bpasero للأسف لا. ومع ذلك ، فهو يعتمد على Ext JS ، وهذا هو المكان الذي توجد فيه غالبية كود (مكتبة). سأحاول استخدام مساحة عمل Ext JS نظيفة بعد الانتهاء من هذا الاختبار الآخر ، ومعرفة ما إذا كانت هناك إعادة نسخ.

@ Elusive138 نعم سيكون من الجيد أن يكون لدينا عينة لإعادة إنتاجها من جانبنا.

يبدو أن إحدى عمليات code.exe (الرمز رقم 3 في السجل ، مرفق) تتسرب. بدأ الالتزام بحوالي 200 ميجابايت الساعة 5:30 مساءً ، ووصل إلى 460 ميجابايت بحلول الساعة 9:00 صباحًا في اليوم التالي ، مع زيادة مستمرة:

لا يرتفع عدد المقبض.

vscode_memleak.zip

لم يكن هناك عطل هذه المرة ، ربما لأنني لم يكن لدي العديد من البرامج الأخرى التي تستهلك ذاكرة كبيرة. قد تكون قادرًا على اختبار ذلك في جهاز افتراضي بحد التزام منخفض لاحقًا.

تم إنشاء هذا السجل بين عشية وضحاها مع فتح 3 مساحات عمل كبيرة في نوافذ مختلفة. سأحاول تضييقه إلى مساحة عمل يمكنني مشاركتها.

@ Elusive138 سيكون من المفيد فهم تفاصيل العملية التي تتسرب. هل يمكنك العثور على PID الخاص به ثم طباعة بياناته الوصفية الكاملة باستخدام ps aux | grep <pid> ؟

آه ، ربما هذا على Windows ، لست متأكدًا :)؟

bpasero سطر الأوامر هو:

"C:\Program Files (x86)\Microsoft VS Code\code.exe" --type=renderer --no-sandbox --lang=en-US --app-user-model-id=Microsoft.VisualStudioCode --node-integration=true --device-scale-factor=1 --enable-delegated-renderer --num-raster-threads=4 --gpu-rasterization-msaa-sample-count=8 --content-image-texture-target=3553 --video-image-texture-target=3553 --disable-accelerated-video-decode --channel="4896.1.1021371100\1043577992" /prefetch:673131151

تفاصيل أخرى:

شجرة العملية:

هذا بعد يوم كامل آخر من الاستخدام. كما ترى ، يبدو أن استخدام ذاكرة العملية قد ارتفع بشكل خطي في ذلك الوقت (نفس مساحة العمل).

آه ... هذا ليس سيئًا حقًا.

4772 هي العملية التي تسربت بين عشية وضحاها. يبدو أن الآخر قد ارتفع بسبب استخدامي أثناء النهار ... أعتقد.

@ Elusive138 يبدو أن لديك العديد من النوافذ المفتوحة باستخدام Code ،

bpasero نعم ، كان الاختبار الليلة الماضية يحتوي على ثلاث نوافذ مفتوحة

يبدو جيدا!

لسوء الحظ ، لا ريبرو ... هذا غريب. ما الذي يمكن أن يتسبب في حدوث تسرب داخل هذا المشروع المحدد؟

بالحديث عن ذلك ، قد يكون هذا مختلفًا عن إصدارTyriar الأولي. لم يكن مستجيبًا ، وأنا و gwynjudd تعطلان مع مربع حوار الخطأ ..؟ في هذه الحالة ربما يجب أن نصدر عددًا جديدًا ...

تضمين التغريدة هل يتكاثر إذا فتحت مساحة العمل هذه دون فتح أي ملف JS؟

أيضًا ، ربما يمكننا البدء في تحديد هذا باستخدام أدوات مطور الكروم حيث يمكنك عمل لقطات سريعة. لذلك ، ما عليك سوى إجراء لقطة قبل وبعد بعض الوقت لمعرفة أين تذهب تلك الذاكرة.

bpasero أوه ، لقد نسيت تمامًا تلك الأدوات المطورة. سأحاول ذلك الليلة.

لقطات bpasero Heap لـ Main.js و workerMain.js و workerMain.js (2) لا تتغير حقًا. ربما 5 ميغا بايت على الأكثر.

إضافة المزيد إلى وضعي ، حاولت تشغيله بمجلد مفتوح (المجلد الذي تعطل) ولكن لا توجد ملفات عمل ولم يحدث ذلك بين عشية وضحاها. لذلك يحدث ذلك فقط عندما يكون المجلد مفتوحًا وهناك ملفات عمل نشطة.

@ Elusive138 ننتج عمليات أخرى يمكن أن تسبب ضغط الذاكرة ولن تظهر في ملف تعريف الكومة. ومع ذلك ، من إحدى مشاركاتك السابقة ، يبدو أنك قد حددت الذاكرة العالية القادمة من عملية العارض والتي يجب أن تظهر تحت لقطة الكومة المفاجئة. هل أنت متأكد أنك رأيت الذاكرة العالية لعملية العارض وليس لأطفالها؟ لأن العارض هو أصل العمليات الأخرى التي يولدها ، على سبيل المثال ، عملية مشاهدة الملف.

Tyriar ، هل يمكنك أن تكون أكثر تحديدًا ما تعنيه بذلك. هل لم تفتح أي ملف في المحرر أم أنك حرفياً قسم ملفات العمل فارغ؟

سبب سؤالي عن فتح ملف أو عدم فتحه هو أنه على سبيل المثال ، لا تبدأ خدمة لغة JS إلا بمجرد فتح ملف JS. وينطبق الشيء نفسه على أي خدمة لغة أخرى. لذلك إذا ظهرت هذه المشكلة دون فتح ملف في المحرر ، فمن المحتمل أن تسرب الذاكرة ليس في أي خدمة لغة ولكن في مكان آخر.

شيء آخر يستحق المحاولة: تشغيل بدون أي امتداد لمعرفة ما إذا كان هناك تسريب من أحد الإضافات. يمكنك الركض بـ --disable-extensions للقيام بذلك.

bpasero أنا متأكد من أن سطر الأوامر المقدم أعلاه كان لـ 4772 ، السطر المميز (المتسرب) في لقطة الشاشة. تقول --type=renderer .

سأترك الأمر يعمل خلال عطلة نهاية الأسبوع مرة أخرى وأرى ما سيحدث. لا أعتقد أنني أجريت اختبارًا نظيفًا بدون فتح ملفات JS حتى الآن.

bpasero أعتقد أنه لم يكن لدي ملف مفتوح (على اليمين) ، فقط ملفات تعمل فوق الشجرة. إذا كنت أتذكر عندما أنهي العمل ، فسأحاول التحقق من فتح ملف ولاحظ اللغة.

لا أعرف على وجه اليقين ولكن ربما لم يكن ملف JavaScript عندما تعطل ملفي ، على الأرجح C ++ أو Java أو بدون لغة. سأكون متأكدا من التحقق.

Tyriar إذا تم إعادة إنتاجه فقط من خلال وجود شيء ما ضمن ملفات العمل ومع إغلاق جميع المحررين (مباشرة من بدء التشغيل - هذا مهم) ، فقد نصل إلى شيء ما.

bpasero قد أحاول فتح مجموعة من الحالات في ظل ظروف مختلفة قبل مغادرة العمل يوم الجمعة ومعرفة ما إذا كان بإمكاني إخراج جميع تجاربي من الطريق في ليلة واحدة. ما لم يكن لديك سبب للاعتقاد بأن حالة واحدة من تعليق vscode ستكسر كل الآخرين؟

Tyriar نعم تمامًا ، إذا كان لديك أكثر من نافذة ، وستتعطل جميعها. هذا لأنه عند فتح نوافذ متعددة ، لا يزالون يشاركون جميع العمليات الأبوية وحد ذاكرة واحد يصل إلى 1-1.5 جيجابايت. لفهم مصدر التسرب حقًا ، من الأفضل قياس نافذة واحدة معزولة في ظل هذه الظروف:

• لم يتم تمكين أي امتداد عبر --disable-extensions (الامتداد الذي يستهلك الكثير من الذاكرة أو التسريبات قد يتسبب أيضًا في حدوث عطل)
• لم يتم فتح أي ملف عند بدء التشغيل (فقط إغلاق ملف بعد فوات الأوان بالفعل)
• لا يوجد ملف عمل تحت ملفات العمل

راجع للشغل الشيء الوحيد لملفات العمل التي قد يكون لها تأثير هو أنه لكل ملف عمل غير موجود داخل مساحة العمل ، نقوم بتثبيت مراقب ملفات لمراقبة التغييرات. ربما هذا يسبب التسرب ، سيكون مفاجئًا. أيضًا ، لا نقوم بتثبيت مراقب إذا كان الملف داخل مساحة العمل المفتوحة ، فقط للملفات بالخارج.

bpasero لا تسريبات في حالة عدم وجود ملفات مفتوحة (؟). سأحاول مساحة العمل النظيفة الليلة بعد التأكد من فتح عدد قليل.

حاولت خلال عطلة نهاية الأسبوع بالإعداد التالي:

1. ابدأ بـ Code --disable-extensions
2. افتح ملف جافا سكريبت 1300 سطر تقريبًا

كانت الذاكرة ووحدة المعالجة المركزية في نفس ليلة الجمعة وصباح الاثنين تقريبًا.

Tyriar هل كان هذا مجرد فتح مساحة عمل فارغة بملف واحد أو فتح مجلد أولاً ثم ملف منه؟

bpasero بفتح مساحة عمل فارغة ، لم أفتح مجلدًا ولم يكن أي مجلد مفتوحًا عند بدء التشغيل

حسنا من الجيد أن أعرف. لذلك يبدو أن هذا مرتبط بفتح مجلد (من المحتمل أن يكون كبيرًا). لا يزال لمعرفة ما إذا كان مجرد فتح هذا المجلد كافيًا أم أن فتح ملف يؤدي فقط إلى تشغيله.

bpasero كان لدي مجلد كبير مفتوح بدون ملفات مفتوحة خلال عطلة نهاية الأسبوع ، مع عدم وجود زيادة ملحوظة في استخدام الذاكرة. سأحصل على نتائج اختبار فتح مجلد وملف كبير مع مساحة عمل قابلة لإعادة الإنتاج / قابلة للمشاركة في حوالي 7 ساعات.

bpasero ، كان المجلد الذي تعرضت فيه لأعطال من قبل 13000-14000 ملفًا قويًا ، وهذا يشمل git repo الذي كان حوالي 2000 بحد ذاته.

أعتقد أنني سأتحقق مرة أخرى من أن التعطل لا يزال يحدث في أحدث إصدار بعد ذلك لأنه مر وقتًا منذ أن رأيته (بسبب الاختبار).

وأفترض أنها مساحة عمل JS؟

bpasero py ، cpp ، js ، html ، css

حسنًا ، يبدو أن هذا يعيد إنتاج استخدام الذاكرة المتصاعد ببطء ، إذا كان على نطاق أصغر: /ext/build/ext-all-debug.js .

(نعم ، إنه 7z داخل ملف مضغوط ... لن يسمح لي GitHub بتحميل 7z أو xz مباشرةً ، كما أن zip و gzip كبيران جدًا)

@ Elusive138 كم يزيد بالنسبة لك في المتوسط؟ كان لدي مساحة عمل مع بعض ملفات JS مفتوحة لمدة ساعتين الآن دون أي زيادة في الذاكرة.

bpasero معذرة ، أواجه مشكلة في إعادة الإنتاج مرة أخرى. أعتقد أنه كان لدي git repo في محاولة سابقة ، لم يتم تضمينه في الأرشيف أعلاه. سأخبرك عندما يكون لدي المزيد من النتائج الملموسة.

سيكون من المفيد حقًا إذا كان من الممكن فتح عدة مثيلات مستقلة ... أن تكون مقيدًا باختبار واحد في الليلة أمر بطيء جدًا. هل تصادف أنك تحمل أعلام Chromium لملفات شخصية منفصلة؟

من الممكن إنشاء إصدارات متعددة من التعليمات البرمجية يمكن تشغيلها بالتوازي ، على الرغم من أننا لم نوثقها. إذا قمت بتغيير القيم في https://github.com/Microsoft/vscode/blob/master/product.json بحيث تكون مختلفة ثم الإنشاء من سطر الأوامر ، يمكنك بدء مثيلات مختلفة متعددة. المعرّفات التي يجب أن تكون فريدة هي:

• darwinBundleIdentifier
• win32MutexName
• الاسم قصير
• الاسم طويل
• dataFolderName (مثل "dataFolderName": ".oss-code-1")

نظام التشغيل Windows 8.1. في Code ، فتح مجلد لمستودع git يحتوي على 39000 ملف في الصباح.
فعلت القليل جدًا معها ، بعض التعديلات الصغيرة في ملفين.
بحلول نهاية اليوم ، بلغ حجم الالتزام الذي أبلغ عنه مدير المهام 672164 ألفًا.
نمت بشكل مطرد طوال اليوم ، حتى عندما لم أكن في البرنامج.

gushie هل يمكن مشاركة هذا الريبو معي؟ أيضا ، ما هي الذاكرة الأولية التي تم الإبلاغ عنها؟

bpasero ، أنا آسف ، لا يُسمح لي بمشاركة الريبو نفسه ولكن إذا كانت هناك أي تفاصيل حوله قد تساعد ، باستثناء محتويات الملف نفسها ، فأعلمني بذلك. تبدأ العملية مبدئيًا عند حوالي 110 ميجا بايت ، ثم تنمو بسرعة إلى حوالي 130 ميجا بايت قبل أن تستقر مرة أخرى على 90 ميجا بايت. ثم ستنمو بشكل مطرد من هذه النقطة إلى الأمام. (هناك 5 عمليات أخرى لـ code.exe والتي تتراوح من 4 ميجا بايت إلى 30 ميجا بايت ولكنها لا تنمو بشكل ملحوظ. هناك فقط نافذة التعليمات البرمجية واحدة)

لا أعرف ما هو حجم الالتزام النهائي منذ الأمس حيث تعطلت العملية عندما عدت إليها اليوم.

gushie لقد كنت أستخدم مراقب الأداء في عمليات code.exe لمراقبة "الحجم الخاص".

مزعج للغاية لأنه لا يمكننا مشاركة مساحات العمل التي لدينا مشاكل معها! أتساءل عما إذا كان أي شخص قد واجه هذا بشيء مفتوح المصدر. البحث عن أوجه التشابه: هل تم استخدام الريبو الخاص بك من قبل مع git-svn؟

bpasero شكرًا ، إذا لم يتم إعادة إجراء العملية التي تركتها عندما أعود يوم الاثنين ، فقد أحاول إنشاء نسختين إضافيتين. قد تحتاج إلى معرفة كيفية تتبع أي واحد ، رغم ذلك .. قد يكون مشكلة.

@ Elusive138 نستخدم أدوات Atlassian ، لذا فإن SourceTree تتصل بخادم Stash خاص

آه ، هذا مختلف تمامًا عن لي. كان Git repo محليًا (w / Git Extensions) متصل بخادم SVN. اختباري الحالي هو مع git repo استنادًا إلى vscode واحد ... آمل أن يتم إعادة نشره ويمكنني مشاركته.

gushie هل يتكاثر إذا فتحت مساحة العمل دون فتح أي ملف؟ حاول أولاً إغلاق جميع الملفات وإعادة التشغيل للحصول على هذا الإعداد. إذا لم يتم إعادة إنتاج ذلك ، فهل يتم إعادة إنتاجه إذا فتحت مساحة العمل وفتحت ملف JS واحدًا وتركته هكذا؟

bpasero لقد تركته مفتوحًا بالفعل مع ملف عمل واحد غير محرر الليلة الماضية ، والتحقق هذا الصباح من أن استخدام الذاكرة لا يبدو أنه قد تغير كثيرًا. لقد قمت الآن بتحرير الملف وإنشاءه ، وسأترك هذا لأرى ما سيحدث.

لاحظ حتى قراءة هذه المشكلة ، لم أقم بمسح ملفات العمل على الإطلاق. (لم أكن بحاجة فعلاً إلى ذلك ، لقد تجاهلت هذه اللوحة بشكل عام وبدلت الملفات عبر مستكشف ملفات المشروع الموجود أسفلها ، أو باستخدام Ctrl + E).

تحطمت مرة أخرى ، كانت هذه المرة بعد الاستخدام المنتظم لكنها تركت في هذه الحالة:

• ~ 14000 ملف مجلد مفتوح
• 5 ملفات عمل نشطة (.cc ، .java ، .h ، .py ، .json)
• لا يوجد ملف مفتوح في محرر النصوص

الناتج ps aux :

❯ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
daniimms  6086  0.0  0.5 970620 92180 pts/0    Sl   Jan11   0:36 /home/local/ANT/daniimms/VSCode-linux-x64/Code /home/local/ANT/daniimms/VSCode-linux-x64/resources/app/out/bootstrap --type=watcherService

كما ذكرنا ، على الرغم من أن هذا تم بعد الاستخدام المنتظم وليس في الوضع الآمن ، فهل كان من الممكن أن يكون بسبب تمديد؟

تركت ملفًا واحدًا به تعديل صغير مفتوحًا ، فقط هذا الملف في ملفات العمل. على خلاف ذلك طوال اليوم. لم تزد الذاكرة من قيمتها الأولية.

Tyriar حسنًا ، العملية التي

gushie هل كان هذا بدون فتح مجلد؟

bpasero لقد فتح المجلد بالفعل. من الواضح أن هناك بعض الإجراءات التي يبدو أنها تطلق تسربات الذاكرة بعد الفتح الأولي لملف داخل المجلد. سأستمر في المراقبة ومحاولة تضييقها.

bpasero كانت هذه هي العملية الوحيدة المتعلقة بـ vscode التي استطعت رؤيتها في الإخراج ، فمن المحتمل أنها لم تكن مرئية في الإخراج لأنها قُتلت بالفعل بسبب عدم الاستجابة؟ كما هو موضح ، كانت العملية تستخدم فقط 0.5٪ من الذاكرة و 0٪ من وحدة المعالجة المركزية. أعتقد أنه من خلال اكتشافاتي الأخيرة ، ربما لا تكون المشكلة التي أواجهها بسبب خدمة JS.

راجع للشغل حتى لو لم نجد سبب ذلك حتى نهاية الشهر ، فقد قمت بإجراء تغيير بحيث يحدد مربع حوار التعطل الذي تحصل عليه افتراضيًا إجراءً لإعادة فتح النافذة حتى تتمكن من متابعة العمل من حيث تركت. هذا مفيد أيضًا للحالة حيث يكون لديك عدة نوافذ مفتوحة وتعطل واحدة منها فقط.

(هناك شيء واحد مفقود وفي المستقبل هو أن تكون قادرًا على مسح حالة واجهة المستخدم بشكل دوري على القرص حتى تؤدي إعادة الفتح أيضًا إلى استعادة بيئة عملك السابقة)

bpasero : +1: سيكون ذلك مفيدًا.

لقد تحطمت VS كل صباح منذ حوالي شهر الآن. لقد وصلت إلى نهاية صبري.

آمل أن يتم التعامل مع هذا باعتباره خطأ PRI 0 لأن أي محرر عاقل لا يجب أن يتعطل هذا كثيرًا.

يرجى إعلامي كيف يمكنني الحصول على تتبع حول سبب حدوث ذلك. لقد رأيت هذا يحدث على أجهزة أخرى أيضًا.

nojvek هل أنت قادر على مشاركة مساحة العمل معي حيث يحدث هذا؟

لست متأكدًا مما تقصده بمشاركة مساحة العمل. إنه مشروع مطبوع / HTML / CSS بقليل من c ++. حوالي 1500 ملف و 80000 سطر من التعليمات البرمجية.

هل هناك طريقة في VS لإظهار حوادث الاصطدام؟

nojvek @ أود أن يكون لدي مساحة عمل يمكنني تشغيل التعليمات البرمجية بها لإعادة

بنيامين،

كود مصدر Microsoft الداخلي ولا أعتقد أنه يمكنني إعطائه لك.

إذا كانت هناك بعض أدوات مراقبة الذاكرة يمكنني إضافتها ، فأخبرني بذلك.

هل ستنجح إذا أخذت لقطات للذاكرة باستخدام مصحح أخطاء الكروم المضمن
في vscode كل بضع ساعات لمعرفة ما يجري؟

يوم السبت الموافق 23 يناير 2016 ، بنيامين باسيرو إخطارات github.com
كتب:

nojvek https://github.com/nojvek أود أن يكون لدي مساحة عمل
يمكنني تشغيل التعليمات البرمجية باستخدام إعادة إنتاج هذه المشكلة. نشك في أنه مرتبط بـ
تسرب الذاكرة في مكان ما ، فمن غير الواضح أين. إذا كنت تستطيع أن ترسل لي الرمز البريدي
مساحة العمل أو ربما عنوان URL git إذا كان مفتوح المصدر.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174192367.

نعم ، ستساعد لقطات الذاكرة في حالة وفقط إذا كان هذا التسريب داخل الجانب الرئيسي من VS Code. ومع ذلك ، يبدو أنه في حالة واحدة على الأقل كان التسرب في إحدى العمليات التي ننتجها (مراقب الملفات). ربما يمكنك تحديد استخدام مستكشف العمليات ، أي عملية تتزايد باستمرار من حيث استهلاك الذاكرة.

إذا كان ذلك يساعدني على تزويدني بكود المصدر: فأنا أعمل لدى Microsoft ؛)

سآخذ كلمة مع مديري. هذا في Windows repo لذا سأضطر إلى ذلك
كن حذرا قليلا.

من الخيط يبدو أن chokidar يستخدم لمراقب الملفات. فترة
لقد لعبت مع شفرة المصدر. كان قليلا من السباغيتي.

سأرى ما إذا كان بإمكاني تحميل chokidar على تطبيق العقدة البسيط الخاص به ومعرفة ما إذا كان كذلك
الجاني.

راجع للشغل أي أسباب محددة لماذا يحتاج إلى استخدام Chokidar؟ هناك المزيد
عبر مراقبي ملف منصة أليس كذلك؟

في يوم الأحد ، 24 يناير 2016 ، بنيامين باسيرو إخطارات github.com
كتب:

نعم ، ستساعد لقطات الذاكرة في حالة وفقط إذا كان هذا التسريب داخل الجهاز الرئيسي
جانب من رمز VS. ومع ذلك ، يبدو أن التسريب كان في حالة واحدة على الأقل
في إحدى العمليات التي ننتجها (مراقب الملفات). ربما تستطيع
تحديد استخدام مستكشف العمليات ، أي عملية تتزايد باستمرار في
شروط استهلاك الذاكرة.

إذا كان ذلك يساعدني على تزويدني بكود المصدر: فأنا أعمل لدى Microsoft ؛)

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -174269028.

يتم استخدام Chokidar على نظامي Mac و Linux ، إذا كنت تستخدم نظام Windows ، فنحن نستخدم مراقب ملفات C #. يسعدني قبول العلاقات العامة مع حل مراقب الملفات المتقاطع العامل والأداء :)

أنت تعرف اعتبارًا من العقدة 4.0 ، يتم تثبيت fs.watch على كل من windows و mac. راجع: https://github.com/Microsoft/TypeScript/issues/4643.

يحتوي Typescript على منطق مشاهدة ملف / دليل قوي عبر النظام الأساسي. https://github.com/Microsoft/TypeScript/blob/931d162620c7e09377c12875834e1838c4cdd51b/src/compiler/sys.ts

سأحاول الحصول على بناء محلي من كود VS مع تغيير ومعرفة ما إذا كان لا يزال يتعطل. إذا لم يكن الأمر كذلك ، فسأرسل بالتأكيد PR.

أعلم أنه أصبح أفضل بكثير من خلال استخدام مكالمة المشاهدة المتكررة في الدليل وبالتالي تجنب الاضطرار إلى إرفاق مستمع مشاهدة لكل مجلد ، لكنني أعتقد أن الأحداث لا تزال تفتقد أحيانًا اسم الملف / المجلد ، على الأقل في بعض الحالات. أشعر بمزيد من الثقة باستخدام C # هنا.

تمكنت من الحصول على تأنيب اليوم. لقد تعطلت للتو قبل أن أسحب وحدة تحكم أدوات المطور لأخذ لقطة للذاكرة.

http://i.imgur.com/rirFul1.png

يبدو أن خادم الطباعة يستغرق حوالي 200 ميغا بايت.
استهلك جهاز العرض حوالي 800 ميغا بايت ثم تعطل.

عندما أحصل على 500 ميغا بايت من الاستخدام ، سأحاول التقاط لقطة للذاكرة. - عملية العارض هل عملية webkit صحيحة؟

كان هذا بعد يومين منذ آخر مرة رأيت فيها حادثًا. يبدو أن استخدام الأداة لمدة 8 ساعات يؤدي تحرير الكثير من ملفات TS إلى الاستخدام بشكل أسرع.

رائع ، عملية العارض هي العملية الرئيسية للمحرر. إذا كان بإمكانك عمل لقطة للذاكرة هناك ، فستجلبنا إلى أبعد من ذلك. لسوء الحظ ، لن تعمل اللقطة مع أي من العمليات الأخرى ، ولكن يبدو أن هذه العمليات لا بأس بها.

هل من الطبيعي أن يستهلك خادم tscse (الخادم المطبوع) 200 ميغا بايت رغم ذلك؟

يوم الثلاثاء ، 26 يناير 2016 ، الساعة 9:29 مساءً ، بنيامين باسيرو إخطارات @github.com
كتب:

رائع ، عملية العارض هي العملية الرئيسية للمحرر. اذا أنت
يمكن إجراء لقطة للذاكرة هناك ستجلبنا إلى المزيد. لسوء الحظ، ال
لقطة لن تعمل مع أي من العمليات الأخرى ، ولكن يبدو أن هذه
كن بخير.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -175408302.

نعم ، من السهل جدا.

هههه! كنت بصدد أخذ لقطة كومة وتحطمت VS.

سأحاول مرة أخرى وأرى ما إذا كان لديّ حظ أفضل غدًا.

هل هناك طريقة لإخبار vscode بزيادة حد الذاكرة الخاصة به حتى لا يتعطل أثناء محاولة التقاط لقطة كومة؟

أعتقد أن ما يحدث هو أن أخذ اللقطة تسبب في استثناء نفاد الذاكرة: - /. لا توجد طريقة لتغيير حد الذاكرة ، فهي مشفرة بشكل ثابت في V8.

ربما تحاول أخذ اللقطة في وقت أبكر قليلاً ، قبل أن يزداد استخدام الذاكرة بشكل كبير؟ هل هي زيادة تدريجية؟

لم أتمكن من إعادة الإنتاج (بدون أعطال ، استخدام معقول للذاكرة) خلال الأسبوعين الماضيين أو نحو ذلك. الاختلاف الوحيد الذي يمكنني التفكير فيه هو تحديث ملحق PowerShell من 0.1.0 إلى 0.3.1 - لكن ليس لدي أي ملفات PS في مساحة العمل على أي حال ، وقد تعطلت مع الملحقات المعطلة في ذلك الوقت.

لقد حصلت على تفريغ ناجح لحوالي 300 ميغابايت استخدمته عملية العارض. لقد تحطمت بعد 10 ثوانٍ من أخذ مكب النفايات.

يبدو أن الجزء الأكبر من الاستخدام موجود في شجرة DOM.

https://www.dropbox.com/s/dk5exyke3fqgahk/VS.heapsnapshot؟dl=0

أتمنى أن يساعدك هذا.

حسنًا ، أتساءل عما إذا كان المحلل يقول الحقيقة الحقيقية هنا. أرى جميع عناصر الشجرة وقد يكون لدينا أيضًا تسرب في الشجرة ، لكن سأندهش من أن هذا التسرب قد يتسبب في نفاد الذاكرة في مثل هذه الفترة القصيرة من الزمن.

أخذت بضعة مكبات أخرى.

يبدو أن فتح ملفات .min.js يتسبب في قفزة هائلة في الذاكرة. حتى بعد إغلاق الملفات ، لا يبدو أن الذاكرة تنخفض. بين كل مقالب الذاكرة يبدو أن DOM هو المسيطر.

لست متأكدًا أيضًا من سبب وجود عمليتين للعارض. قد يكون أحدهم هو أدوات تطوير الكروم. لكنني اقتربت جدًا من حفلة واحدة.

https://www.dropbox.com/sh/3t238zx7l3vfpzx/AABCbFBNYLzHinkN7OTe6ubya؟dl=0

لقد التقطت لقطة شاشة للعملية التي تستهلك حوالي 500 ميجابايت من ذاكرة الوصول العشوائي.

نعم ، واحد هو devtools. من المتوقع أن تزداد الذاكرة عند فتح الملفات. لكني أود أن أفهم كيف يزيد رمز VS الذي يعمل ليلاً بدون نشاط في استخدام الذاكرة حتى يتعطل.

حسنًا ، فإن repro هو:
ابدأ مقابل الكود.
افتح ملفًا أو ملفين js / ts على مجلد كبير به الكثير من ملفات .tsconfig.
قم ببعض التمرير / التحرير.
أغلق جميع ملفات العمل.
ضعه في درجة حرارة 200 مئوية بين عشية وضحاها.
كيك!

في يوم الجمعة ، 29 يناير 2016 ، بنيامين باسيرو إخطارات github.com
كتب:

نعم ، واحد هو devtools. من المتوقع أن ترتفع الذاكرة عند الفتح
الملفات. لكني أود أن أفهم كيف يتم تشغيل رمز VS
الليل بدون نشاط يزيد في استخدام الذاكرة حتى تتحطم.

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177087988.

nojvek هل .tsconfig s ضرورية للتعبير؟ لأنني تعرضت لحوادث في الماضي دون أي شيء يتعلق بـ TS على الإطلاق. على الرغم من أنني لا أستطيع حتى توبيخ هؤلاء بعد الآن ...

مشروعنا هو مجرد وجود لهم. يمكن أن يكون رنجة حمراء.

في يوم السبت ، 30 يناير 2016 ، كتب Bob [email protected] :

nojvek https://github.com/nojvek هل ملفات .tsconfigs ضرورية ل
ريبرو؟ لأنني تعرضت لحوادث في الماضي دون أي شيء يتعلق بـ TS في
الكل. على الرغم من أنني لا أستطيع حتى توبيخ هؤلاء بعد الآن ...

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177198518.

ملفات. * الوحيدة الموجودة في مجلدنا هي مجلد .git و .gitignore

nojvek هل تستخدم

bpasero nojvek إذا كانت مشكلة في الذاكرة من جانب JS. يمكنك مقارنة لقطة الكومة المفاجئة على Chrome.

1. خذ لقطة.
2. قم بالإجراء الذي يسبب تسرب الذاكرة.
3. فرض جمع القمامة. وإلا فإن لقطة الكومة التالية ستتضمن الكائنات.
4. خذ لقطة أخرى.
5. فرق كل لقطة.

يمكن فعل كل شيء باستخدام Chrome Devtools أعلاه. قوة جمع البيانات المهملة موجودة في علامة تبويب الجدول الزمني ، أيقونة القمامة. ويتم الاختلاف عن طريق اختياره في مستكشف اللقطات في قائمة التصفية.

ما عليك سوى الإبلاغ عن الكائنات التي يتم الاحتفاظ بها ومسارات الاحتفاظ المحتملة (أسفل جدول الكومة مباشرةً). وهذه هي كل البيانات اللازمة لإصلاح هذه المشكلة.

لا داعي للانتظار يومًا كاملاً لجمع البيانات حول الانهيار: غمزة:

يحتوي رابط Dropbox الذي أرسلته على ثلاث لقطات حرارية بفاصل نصف ساعة.
لم أفعل قوة جمع القمامة. سوف يعطي ذلك خدعة.

في يوم الأحد ، 31 يناير 2016 ، كتب Tingan Ho [email protected] :

bpasero https://github.com/bpasero nojvek https://github.com/nojvek
إذا كانت مشكلة في الذاكرة من جانب JS. يمكنك تفريق لقطة الكومة المفاجئة
كروم.

1. خذ لقطة.
2. قم بالإجراء الذي يسبب تسرب الذاكرة.
3. فرض جمع القمامة. وإلا فإن لقطة الكومة التالية سوف
   تشمل الأشياء.
4. خذ لقطة أخرى.
5. فرق كل لقطة.

يمكن فعل كل شيء باستخدام Chrome Devtools أعلاه. قوة القمامة
المجموعة في علامة تبويب المخطط الزمني ، أيقونة القمامة. والفارق هو
يتم ذلك عن طريق اختياره في مستكشف اللقطات في قائمة التصفية.

ما عليك سوى الإبلاغ عن الكائنات التي يتم الاحتفاظ بها ومسارات الاحتفاظ الممكنة (أدناه
جدول الكومة). وهذه هي كل البيانات اللازمة لإصلاح هذه المشكلة.

لا داعي للانتظار يومًا كاملاً لجمع البيانات حول حادث تحطم [الصورة:
:غمزة:]

-
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -177462412.

لدي نفس المشكلة ، VS Code يتعطل باستمرار ، ليس فقط خلال الليل ، حتى بعد 30 دقيقة من الخمول.
أنا أستخدم Windows 7 و 64 بت وأحدث إصدار من VS Code. فيما يتعلق بالمشروع نفسه ، فهو مشروع js ضخم ، مع تحميل node_modules و bower_components أيضًا. يحتوي إجماليًا على حوالي 40 كيلوبايت من الملفات.

خطوات التكاثر:
1) افتح مجلد المشروع (مع الكثير من الملفات) ، افتح عدة ملفات بحيث يمكن أن تكون في قائمة ملفات العمل.
2) افتح مدير المهام.
3) ضع المؤشر لتركيز بعض الملفات في VS Code
4) مشاهدة الذاكرة ترتفع خلال الوقت.

هل يمكن للأشخاص الذين لديهم مساحات عمل JS الذين يرون هذه المشكلة منح 0.10.7 من المطلعين لدينا تجربة (https://vscode-builds.azurewebsites.net/insider) مع خيار استخدام Salsa كخدمة لغة JS: https://github.com /Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript - معاينة salsa

شكر!

+1 لهذه المشكلة. تظهر أيضًا على Windows. إنه أمر مزعج تمامًا وأنا لا أحبه.

bpasero أود تجربة الإصدار الجديد ، ولكن عندما أحاول الوصول إلى الرابط الذي قدمته (https://vscode-builds.azurewebsites.net/insider) ، أحصل على صفحة رسالة خطأ غير مفيدة للغاية بالنص التالي :

تسجيل الدخول
معذرة ، لكننا نواجه مشكلة في تسجيل دخولك.
لقد تلقينا طلبًا سيئًا.

معلومات فنية إضافية:
معرف الارتباط: e477dc1b-c193-4cf9-864b-1d3fdbba4f34
الطابع الزمني: 2016-02-03 19: 37: 17Z
AADSTS50020: حساب المستخدم " [email protected] " من موفر الهوية " https://sts.windows.net/5a7d8144-6966-4b1e-8147-de672a307ea0/ " غير موجود في المستأجر "Microsoft" ولا يمكنه الوصول إلى التطبيق " 9d5f02f6-ffd9-4e80-92d5-e42c85e09bc9 'في ذلك المستأجر. يجب إضافة الحساب كمستخدم خارجي في المستأجر أولاً. قم بتسجيل الخروج ثم تسجيل الدخول مرة أخرى باستخدام حساب مستخدم Azure Active Directory مختلف.

لا يمكنني تنزيل الإصدار وتجربته بسبب هذه المشكلة.

آه آسف ، رابط خاطئ ، يرجى استخدام https://code.visualstudio.com/insiders

bpasero شكرًا ، لديّ المطلعون على الإنترنت الذين يعملون مع Salsa باعتبارها خدمة لغة JS. سأخبرك كيف ستسير الأمور في اليوم التالي أو نحو ذلك

bpasero ، حاولت إطلاق سراح المطلعين ولا تزال المشكلة قائمة ، بعد ليلة واحدة في الخمول VS Code تعطلت.

milenkovicgwynjudd سيتعين عليك أيضًا اتباع الخطوات لتمكين Salsa كما هو موضح في https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/latest.md#javascript --- salsa- معاينة

bpasero ، لقد كنت محقًا ، تمكين Salsa من إصلاح المشكلة. تركت VS Code مفتوحًا في عطلة نهاية الأسبوع وما زال لم ينهار.

من الجيد سماع ذلك! سيكون مثيرًا للاهتمام إذا تمكن الآخرون من التحقق من ذلك أيضًا عن طريق المحاولة.

bpasero لقد قمت بتمكين السالسا وتركتها تعمل خلال عطلة نهاية الأسبوع. هذا الصباح تحطمت.

الكتابة المثبتة

$ npm install -g typescript<strong i="6">@next</strong>
C:\Users\mapatel\AppData\Roaming\npm\tsserver -> C:\Users\mapatel\AppData\Roaming\npm\node_modules\typescript\bin\tsserver
C:\Users\mapatel\AppData\Roaming\npm\tsc -> C:\Users\mapatel\AppData\Roaming\npm\node_modules\typescript\bin\tsc
C:\Users\mapatel\AppData\Roaming\npm

لقد قمت بتعيين settings.json ليكون

{
    "typescript.tsdk": "C:/Users/mapatel/AppData/Roaming/npm/node_modules/typescript/lib"
}

والبيئة المحيطة

$ setx VSCODE_TSJS 1

SUCCESS: Specified value was saved.

ما زلت لا أرى السالسا في تذييل VS code insider.

nojvek لقد فعلت ما فعلته بشكل أساسي ، وأرى Salsa في التذييل ، ولكن فقط عندما يكون ملف .js مفتوحًا ومرئيًا في المحرر

gwynjudd أفترض أنك حصلت على مربع حوار التعطل والآن مع خروج 0.10.8 هل تمكنت من إعادة فتح النافذة؟

bpasero ، نعم ، حصلت على مربع حوار التعطل الجديد ويمكنني إعادة التشغيل

جوين جود

-------- رسالة أصلية --------
من: بنيامين باسيرو
التاريخ: 02/09/2016 19:13 (GMT + 12: 00)
إلى: Microsoft / vscode
نسخة إلى: جوين جود
الموضوع: Re: [vscode] حدوث عطل عند التشغيل بين عشية وضحاها (# 508)

gwyn juddhttps: //github.com/gwynjudd أفترض أنك حصلت على مربع حوار التعطل والآن مع 0.10.8 خارج هل تمكنت من إعادة فتح النافذة؟

يمكنك الرد على هذه الرسالة الإلكترونية مباشرةً أو عرضها على Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181726111.

gwynjudd هل هذه مساحة عمل JS فقط أم أنواع ملفات أخرى مثل PHP مضمنة؟

يوجد العديد من أنواع الملفات في bpasero بما في ذلك الكتابة المطبوعة و java script و css و less و aspx و cs

جوين جود

-------- رسالة أصلية --------
من: بنيامين باسيرو
التاريخ: 02/09/2016 22:49 (GMT + 12: 00)
إلى: Microsoft / vscode
نسخة إلى: جوين جود
الموضوع: Re: [vscode] حدوث عطل عند التشغيل بين عشية وضحاها (# 508)

gwyn juddhttps: //github.com/gwynjudd هل هذه مساحة عمل JS فقط أم أنواع ملفات أخرى مثل PHP مضمنة؟

يمكنك الرد على هذه الرسالة الإلكترونية مباشرةً أو عرضها على Gi tHubhttps: //github.com/Microsoft/vscode/issues/508#issuecomment -181786273.

مع التصميم الجديد ، انهار كل صباح عند تركه يعمل طوال الليل. لدي فقط هذه الملحقات المثبتة (في البناء الجديد ، في إصدار الإصدار ، كان لدي امتدادات مختلفة):

هذا الصباح عندما جئت إلى العمل ، لم يكن قد تحطم. لم أفعل أي شيء مختلف قبل أن أغادر العمل يوم الجمعة.

يجب أن تحاول التكاثر باستخدام مساحة عمل Chromium باستخدام Ubuntu كما يبدو أن Tyriar لديه إعداد مثل هذا عندما حدث.

اتبع التعليمات هنا للحصول على الكود https://www.chromium.org/developers/how-tos/get-the-code

لقد لاحظت أيضًا تأخرًا في Code بعد بعض الوقت من استخدامه ، وحوادث في نهاية المطاف. لقد لاحظت أنه عندما يصبح بطيئًا ، يمكنني تشغيله بشكل أكثر سلاسة إذا قمت بالضغط على F1 واكتب "إعادة تحميل النافذة". يبدو أن هذا يوضح المشكلة في الوقت الحالي ، وبعد ذلك يمكنني حلها في الوقت الحالي. أنا مهتم بالتأكيد برؤية هذا ثابتًا.

من خلال القراءة من خلال هذا الموضوع ، أعتقد أيضًا أنه بسبب عملية العرض ، على الرغم من أنني لم أقم بأي اختبار بها ، ويبدو أنه يحدث بغض النظر عن كمية ملفات العمل في القائمة في لوحة المستكشف ، سواء أو لا يكون الملف مفتوحًا عند تحميل الكود ، ربما تكون أحجام الملفات قيد العمل حاليًا ، ولست متأكدًا مما إذا كان له علاقة بمدقق git diff أم لا ، لكنني أشك في أنه سيكون الجاني .

أنا أيضًا على نظام التشغيل Mac OS X El Capitan 10.11.3 ولم أشاهد المشكلة بالفعل على Windows عندما استخدمته في المنزل ، لكن ليس لدي شجرة عمل ضخمة لأي مشاريع في المنزل ، فقط مجلد ضخم أعمل منه في العمل.

أتمنى أن تكون كلتا المشكلتين مرتبطتين ولكني أخشى ألا يحدث ذلك: يرى معظم الناس هنا أن الكود يتعطل عند تركه قيد التشغيل دون أي تفاعل من المستخدم ، وهو ما يبدو مريبًا للغاية. قد يكون سبب تعطل الكود في النهاية مع استثناء نفاد الذاكرة أثناء استخدامه لفترة طويلة هو حدوث تسريبات أخرى في الذاكرة. من الناحية المثالية ، كلتا القضيتين متماثلتان :)

من الناحية الفنية ، يبدو أنه يتباطأ ويتعطل حتى لو لم أستخدمه أيضًا ، لكنني لست متأكدًا مما إذا كانوا أيضًا يعانون من نفس الشيء ، في هذه الحالة. في كلتا الحالتين ، تبدو الأعراض متشابهة على الأقل. إذا تبين أن مشكلتي ليست ذات صلة ، يمكنني إنشاء مشكلة منفصلة بدلاً من ذلك.

cwadrupldijjit إذا رأيت مشكلة

سوف اري ماذا يمكنني ان افعل. عادةً ما أضع جهاز Mac للنوم ليلاً ، لذلك لا يحدث شيء خلال ذلك الوقت. سأحاول الاحتفاظ بها في الليل وإعلامك في الصباح إذا حدث شيء ما. سأبقيك أيضًا على اطلاع إذا كان بإمكانك الوصول إلى مساحة العمل الخاصة بي.

يبدو جيدا. شكر!

K. لذلك تركت مثيل الكود يعمل طوال الليل ، ولم أواجه مشكلة في تعطله أو الشعور بالبطء على الفور. واصلت العمل اليوم ، وحتى أنني أخذت استراحة صغيرة من استخدامه أثناء القيام بأشياء أخرى ، وبدأت في التباطؤ مرة أخرى. يبدو تقريبًا أنه ربما لا تكون المشكلة ناتجة عن استخدامه بشكل نشط ، ولكن يبدو أيضًا أن شيئًا آخر تسبب في حدوثه أثناء الوقت الذي كنت أعمل فيه.

سأقوم بتشغيل ملف التعريف لأراقب ذلك ، وسأقوم بإنشاء مشكلة جديدة إذا كانت هناك نتائج أخرى مختلفة عن تلك الموضحة أعلاه.

لم أتحقق لمعرفة ما إذا كان يمكنك الوصول إلى مساحة العمل الخاصة بي ، على الرغم من أنني أشك في أنه لا يمكنني مشاركة ذلك معك ، للأسف.

حاولت تشغيل ملف التعريف أمس عندما كان بطيئًا بشكل خاص وعندما كنت آخذ لقطة كومة ، تجاوز الكمبيوتر الحد الأقصى من ذاكرة الوصول العشوائي المتاحة ، وبالكاد يمكنني فعل أي شيء على الإطلاق ، ولا حتى فرض رمز الإغلاق ، لذلك كان علي إعادة التشغيل الكمبيوتر. سأحاول تشغيله في وقت أقرب مما كان عليه من قبل لتجنب حدوث ذلك مرة أخرى.

هذا خارج الموضوع قليلاً ، لكنك قمت بنشر رابط إنشاء المطلعين ، والذي قمت بزيارته. كنت أرغب في تنزيل إصدار windows (كما أستخدم ذلك في المنزل) ، وكلما حاولت الوصول إلى هذا الرابط ، يتم إعادة توجيهي أولاً إلى صفحة التنزيل المعتادة ، ولكن بعد ذلك يعيد توجيهي على الفور إلى الصفحة الرئيسية دون بدء التنزيل. في الواقع ، تقوم بالكتابة فوق محفوظات صفحة التنزيل التي كنت أستخدمها ، لذا لا يمكنني حتى الرجوع إلى التاريخ للوصول إليها. هل هناك أي طريقة أخرى يمكنني من خلالها بناء المطلعين؟

تضمين التغريدة

هذا خارج الموضوع قليلاً ، لكنك قمت بنشر رابط إنشاء المطلعين ، والذي قمت بزيارته. كنت أرغب في تنزيل إصدار windows (كما أستخدم ذلك في المنزل) ، وكلما حاولت الوصول إلى هذا الرابط ، يتم إعادة توجيهي أولاً إلى صفحة التنزيل المعتادة ، ولكن بعد ذلك يعيد توجيهي على الفور إلى الصفحة الرئيسية دون بدء التنزيل.

نأسف لذلك ، لكن بعض المستخدمين أبلغوا عن مشكلة غريبة في بنية المطلعين وقمنا بإزالتها مؤقتًا حتى نفهم هذه المشكلة.

egamma تساءلت عما إذا كان يتعذر الوصول إليها بسبب ذلك. سوف أراقب متى يعمل ، إذن.

Tyriar لقد جربت مساحة عمل الكروم طوال الليل على Linux و Windows و Mac ولم أتمكن من إعادة إنتاج التعطل. هل يمكنك المحاولة مرة أخرى من فضلك؟

لست متأكدًا مما إذا كان هذا مرتبطًا ولكنني لاحظت أن VS Code يميل إلى التعطل خلال يوم عملي إذا فتحته ونسيت أمره لفترة. أنا في العمل لمدة 11 ساعة وعمومًا أفتح الكود أول شيء في الصباح. في مرحلة ما خلال اليوم ، سيتباطأ جهاز الكمبيوتر الخاص بي ويبدأ في التعليق حتى يتعطل أو أقوم بقتله بالقوة.

فقط في حالة ما قد يساعد ...

المشروع الأساسي الذي فتحته في VS Code هو نسخة غير معدلة نسبيًا من عربة التسوق تسمى BVCart (الإصدار 2004.7). لدي ما يقرب من 25-30 ملف عمل في الوقت الحالي ، وحتى مجرد فتح VS Code وعدم لمسها طوال اليوم يؤدي إلى تعطل.

يتألف المشروع من 1836 ملفًا و 130 مجلدًا يبلغ إجمالي حجمها حوالي 35 ميجا بايت وهو موجود في مستودع git صغير.

ZombieProtectionAgency هل من الممكن مشاركة مساحة العمل معي؟

bpasero معذرة ، بالتأكيد لم أتمكن من مشاركتها :( لم أبحث عنها ولكن قد تتمكن من العثور عليها عبر الإنترنت في مكان ما. إنها مجرد عربة تسوق ASP VB.Net قديمة الطراز مسطحة. الغالبية العظمى من الملفات هي .vb مع aspx و ascx وحفنة صغيرة من ملفات css.

أواجه نفس الخطأ بالضبط. يتعطل VS Code كل بضع دقائق. أنا أستخدمه مع الدردار. لا تصطدم عند تركها. يتعارض في غضون دقائق بعد أن أبدأ في إنهاء الملف. لقد كان الأمر كذلك خلال الأيام الثلاثة الماضية مما جعل VS Code غير قابل للاستخدام. كيف يمكنني التحقق مما يجري؟ أنا أستخدم الإصدار 0.10.10.

كان لدي فكرة أخرى: لدينا خدمة يمكنها تلقي مخرجات من نقاط نهاية مختلفة (بوابة ، مهام ، امتدادات) وهذا شيء يمكن أن يحدث في الخلفية ويضيف ما يصل. لقد قمنا ببعض الإصلاحات في هذا المجال لـ GA غير الموجودة في الإصدارات السابقة.

إذا كان أي شخص يعاني من أعطال ليلية يمكنه فقط التحقق لفترة وجيزة مما إذا كان هناك أي إخراج تم تسجيله من الخلفية؟ يمكنك رؤية ذلك من عرض> تبديل الإخراج ثم التبديل بين القنوات من القائمة المنسدلة.

تضمين التغريدة
في إخراج "المهام" ، أرى فقط الإخراج الذي أتوقعه من مهمة الترجمة الخاصة بي.
في إخراج "Git" ، أرى عددًا قليلاً من أدوات git fetch ، تتخللها بعض عروض git show. لست متأكدًا من عدد المرات على الرغم من عدم وجود طابع زمني. لا يوجد إخراج آخر بالرغم من ذلك.

نقوم بجلب تلقائي بين الحين والآخر ، لكن الناتج الرئيسي الذي تراه هناك ربما يكون من العمل الذي تقوم به داخل VS Code. سيكون مثيرًا للاهتمام إذا تمت إضافة الإخراج عندما يكون VS Code في الخلفية. هل المهمة تعمل باستمرار أم فقط عندما تستدعي صراحة مهمة الترجمة؟

المهمة هي فقط عندما أكون ctrl + shift + B وتنتهي بعد ذلك بوقت قصير. لقد تعرضت لحوادث عندما لم أقم بتشغيل مهمة.

أحصل على عرضي git متطابقين عندما أقوم بالتبديل بين الملفات ونعم يحدث جلب git تلقائيًا مرة واحدة كل دقيقتين.

لاحظ أنني لا أفعل أي عمليات سحب وما إلى ذلك داخل VSCode ، فأنا أستخدم SourceTree لجميع المهام المتعلقة بالبوابة.

bpasero سأترك نافذة الإخراج اليوم وأرى ما إذا كان هناك أي شيء يظهر. تم فتحه حاليًا لمدة ساعة أو نحو ذلك من الاستخدام العادي ولا أرى أي شيء في المهام أو طرق عرض git. نحن لا نستخدم git ، لذلك لا أتوقع أن أرى أي شيء في ذلك كقاعدة عامة.

تم إصدار أحدث إصدارات المطلعين لدينا ، وسأكون ممتنًا لو قام الأشخاص بتجربتها في هذه المشكلة: https://code.visualstudio.com/insiders

bpasero لا يزال لدي الإصدار السابق من المطلعين ، هل يمكنني تشغيل ذلك والقيام "بالتحقق من التحديثات" ، أو هل يجب علي تحديث البنية من الرابط الذي قدمته؟

سأحاول وأعود إليك. لأكون صادقًا ، أرى عددًا أقل من VSCode
تعطل في الوقت الحاضر. لا يتحطم على الأقل كل يوم.

يمكنني جعله يتعطل عن طريق فتح ملف ضخم به مليون سطر زائد
js مصغرة والتمرير لأعلى ولأسفل بشكل متكرر. لكني أعرف ما هو
دفع حدود المحرر.

كل ما كنت تضيفه مثل الصلصة السحرية يعمل معي.

الأربعاء، 16 مارس 2016 الساعة 12:29 مساء، بينجامين باسيرو [email protected]
كتب:

تم إصدار أحدث المعلومات الداخلية لدينا وسأكون ممتنًا لو استطاع الناس ذلك
جربه في هذه المشكلة: https://code.visualstudio.com/insiders

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -197503185

gwynjudd ، يجب أن تكون قادرًا على التحديث إذا ظهر شعار VS Code كشعار أخضر:

nojvek نعم هذا يدفع الحدود قليلاً. بالنسبة لإصدار مارس ، أجرينا اختبارًا صريحًا للذاكرة للعثور على المجالات التي يمكننا تحسينها. يتضمن إصدار المطلعين بعضًا من تلك الإصلاحات (ليس كلها ، لقد أجرينا بعض التغييرات بالأمس واليوم والتي لم يتم إدخالها بعد). لذا فضولي فقط إذا كان سيحدث أي فرق للأشخاص الذين يرون هذا ...

bpasero شكرًا لقد فعلت ذلك

bpasero لا يزال

نعم من فضلك ، شكرا.

إليك لقطة كومة مباشرة بعد تشغيل الكود (استخدام الذاكرة حوالي 100 ميجابايت في ذلك الوقت)

كومة-20160318T115937.zip

سأحاول مرة أخرى بعد ساعة أو ساعتين. يبدو أن الشيء الصعب هو الحصول عليه في نقطة زادت فيها الذاكرة إلى حد ما ، ولكن ليس كثيرًا لدرجة أن أخذ اللقطة يؤدي إلى تحطمها من الذاكرة.

لقد رأيت نفس النوع من النتائج عندما حاولت أخذ لقطة كومة (نفدت الذاكرة) ، وهذا ليس ممتعًا.

أشعر أنه لا تزال هناك بعض مشكلات الذاكرة في أحدث إصدار من المطلعين (لنظام التشغيل Mac). سأرى ما إذا كان بإمكاني الحصول على لقطة كومة أخرى دون التضحية بجهاز الكمبيوتر الخاص بي.

bpasero آسف لم أتمكن من الحصول على لقطة من كومة الذاكرة المؤقتة بنجاح حتى الآن. إما أن تكون الذاكرة منخفضة جدًا مثل تلك التي التقطتها من قبل ، أو تقفز لتقول حوالي 500 ميغا بايت أو أكثر ويؤدي التقاط اللقطة إلى حدوث عطل.

لا بد لي من إعادة تشغيل vscode 1-2 مرات في اليوم لأن استخدام الذاكرة يزيد عن 1 غيغابايت وتبدأ الأمور في الشعور بالركود. إنها تستخدم مقدار الذاكرة الذي يستخدمه IDE الكامل ، لذلك هناك بالتأكيد بعض التسريب يحدث.

@ vincent-ly هل يمكنك مشاركة المزيد من التفاصيل حول مساحة العمل التي تراها معها؟

bpasero يوجد حوالي 30-40 ملف js / scss / html يستخدم مكونين من bower مع gulp (بدون عداء مهام vscode). أنا أعمل مع جزأين من المحرر وكثيراً ما أستخدم البحث عن الملفات ، وهو قياسي جدًا. يكون استخدام الذاكرة أقل من 100 ميغا بايت عند بدء التشغيل ، ولكنه يتراكم بمرور الوقت ، حتى عند تقليله.

هل يلعب الذكاء عاملا؟ لدي تعريفات نوع Angular و jQuery مثبتة.

يمكنك تجربة بنائنا الداخلي حيث عملنا على تقليل ضغط الذاكرة لمعرفة ما إذا كان ذلك يجعله أفضل: http://code.visualstudio.com/download؟insiders=true

هل لديك ملحقات مثبتة؟

bpasero مجرد مقتطفات زاوية
https://marketplace.visualstudio.com/items؟itemName=johnpapa.Angular1

سأحاول إنشاء المطلعين وتقديم تقرير ، شكرًا!

+1

رؤية نفس المشكلة على VSCode لنظام التشغيل Windows 0.10.11 . عادة ما تتعطل كل ليلة باستمرار عندما لا تكون قيد الاستخدام. بالنظر إلى الخطوات لجمع المعلومات ، يسعدني تقديم المساعدة.

يعمل على TypeScript git repo مع 28438 ملفًا و 4812 مجلدًا. يحتوي أيضًا على مراقبي gulp ، مع العديد من معرفات TypeSript.

لدي الملحقات التالية مثبتة:

• بوويرشيل
• سي #
• طقم موضوع المواد

alanwright هل يمكنك تجربته إذا كان لا يزال

bpasero تمت إعادة إنتاجه خلال الليل باستخدام

هل يمكنني القيام بأي شيء على جهازي لالتقاط السجلات ومشاركتها معك؟

من فضلك شارك معي على بلدي الاسم المستعار benjpas ، شكرا! نقدر أيضًا بعض التفاصيل حول كيفية استخدامك لـ VS Code في مساحة العمل هذه للتسبب في زيادة الذاكرة.

كما أنني أتعرض للانهيار بين عشية وضحاها وأثناء النهار.

لا يبدو أنه مرتبط بشكل خاص بمساحة عمل أو مساحات عمل صغيرة للغاية من 3 إلى 20 ملفًا أو مساحات عمل ضخمة ، يتم ملاحظتها في الغالب عند فتح نوافذ متعددة.

Repos لقد استخدمت أن تحطمت.
1500+ ملفات asp ، js ، .inc (asp)
70 + ملف asp.net core، js، cshtml
هذا الريبو (https://github.com/gogits/gogs)

@ eByte23 هل تعمل بملحقات أم بدونها؟ على أي منصة أنت؟ هل حاولت مع إطلاق سراح المطلعين؟

bpasero Win10 & OSX مع C # كملحق.
لقد جربت المطلعين ولكن لم يلاحظوا ما إذا كان قد تعطل لأن هناك خطأ في tabbing لذلك توقفت عن استخدامه ولكن يمكنني تركه يعمل طوال الليل لمحاولة التراجع.

@ eByte23 نعم من فضلك. ما علة الجدولة؟

يبدو أن bpasero في الإصدارين الأخيرين من المطلعين مع عرض مسافة بيضاء وتحويل علامات التبويب إلى مساحة بيضاء مع ملف بعلامات تبويب موجودة يبدو أنه يحافظ على علامات الجدولة ولا يكتب مسافات حتى على الأسطر الجديدة.

لم تتح لي الفرصة لإجراء اختبار كامل ولكن سأفعل ذلك الآن.

@ eByte23 أقترح عليك الإبلاغ عن شيء من هذا القبيل كمسألة منفصلة إذا كنت تعتقد أنها واحدة. قدمنا ​​إعدادًا جديدًا editor.detectIndentation والذي يكون افتراضيًا هو true . ربما يمكنك محاولة تعيينه على false .

bpasero يا سيئ ، أنت محق تمامًا في ضبط هذا الإعداد على خطأ
لقد اختبرت برنامج Insider بالأمس بين عشية وضحاها وتحطمت أيضًا.

bpasero يبدو أنكم ربما

لقد استثمرنا كثيرًا في إصلاح تسرب الذاكرة لإصدار 1.0 ، لذلك أتوقع أن يكون الوضع أفضل مع الإصدار 1.0. ولكن لا تزال هناك حالات يحدث فيها ذلك.

قد يكون لدي نظرية جديدة لأنني اكتشفت مؤخرًا أن تطبيقات Electron (إطار عمل UI الخاص بنا) يتم اختناقها بمجرد أن تفقد النافذة التركيز أو تنتقل إلى الخلفية. أتساءل عما إذا كان هذا الاختناق يمكن أن يكون له تأثير على استهلاك الذاكرة.

كلما اختبرت إعادة الإنتاج ، تركت نافذة VS Code مفتوحة مع تركيز لوحة المفاتيح ، لذلك ربما يكون أحد الاختلافات هو السماح بتشغيلها في الخلفية.

هناك طريقة لتعطيل التحكم في الخلفية حتى أتمكن من إنشاء بنية بعلامة لتمكين ذلك.

بخلاف ذلك ، سيكون من المثير للاهتمام أيضًا أن نسمع من الأشخاص إذا كان الانهيار بعد التصغير هو السيناريو المعتاد.

حدثت كل أعطالي عندما لم يكن لدى VSCode تركيز. تحدث بشكل عام بعد تركها في الخلفية طوال اليوم أثناء تصفح الإنترنت أو استخدام Visual Studio

أنا أؤيد هذا. لقد تعرضت مؤخرًا لحادث تحطم. كان مع VS في
الخلفية عندما كنت أركز على سامية لمعظم اليوم.

في يوم السبت ، 16 أبريل 2016 الساعة 11:44 صباحًا ، كتب Toni [email protected] :

حدثت كل أعطالي عندما لم يكن لدى VSCode تركيز. عموما هم
حدث بعد تركه في الخلفية طوال اليوم أثناء تصفح ملف
الإنترنت أو باستخدام Visual Studio

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرةً أو قم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -210872544

تعرضت لتحطم عند استخدام الإصدار الداخلي منذ وقت ليس ببعيد. كان يعمل لمدة يومين. فجأة أصبح بطيئا. تحديد النص بالماوس توقف عن العمل. عملت Shift-Right ولكن ببطء شديد. تعطل التطبيق بعد بضع دقائق من فقدان التركيز.

هذا هو أول تعطل لي بالنسبة للبنية الداخلية ولكن بالنسبة للبنية العادية ، قمت بالترقية إلى الإصدار 1.0 ولا يزال يتعطل كل بضع دقائق أو نحو ذلك بعد الفتح مما يجعله غير قابل للاستخدام. ليس علي حتى أن أفعل أي شيء خاص. افتحه أو عدّل ملفًا (غالبًا ملفات .elm) أو اتركه وسيتعطل. لا تنتظر حتى تفقد التركيز أولاً.

1.0 يتعطل كل ليلة تقريبًا.
نظام التشغيل Windows 10 Ent.
المكونات الإضافية: المدقق الإملائي والنحوي ، ESLint

حسنًا ، تم إصدار إصدار المطلعين مع تضمين التغيير الخاص بي. سأكون سعيدًا إذا قام شخص ما بتجربته :

أي واحد :)؟

استخدامه الآن. لم يكن هناك حادث منذ أمس.

bpasero سأقوم بالترقية الآن

bpasero قمت بتثبيته يوم الجمعة ولكن بعد ذلك ذهبت بعيدًا لقضاء عطلة نهاية أسبوع طويلة ، كما تم إعادة تشغيل جهاز الكمبيوتر الخاص بي في العمل ، لذا ليس لدي أي شيء أبلغ عنه.

@ bpasero تعرض لحادث أمس. بقيت لمدة 3 أيام قبل أن تتحطم.

bpasero ما زلت أرى الانهيار العرضي في الصباح مع أحدث إصدار من المطلعين

أنا أيضا.
ويندوز 8

حزمbpasero Insider 1.1.0 أفضل ، استغرق ما يقرب من أسبوع قبل أن

سألتقط 1.1.0 الآن وأرى كيف ستسير الأمور

لا يمكنني التقاط لقطة كومة دون أن تتعطل عندما يزيد استخدام الذاكرة عن 150 ميجابايت.

كل صباح ، أقوم بإلغاء قفل جهاز الكمبيوتر الخاص بي للعثور على تعطل VS Code بين عشية وضحاها.

• Mac OS X 10.11.4 (15E65)
• كود VS 1.1.0 من الداخل

عادة ما أترك الملفات مفتوحة. أنا أركض مع الامتدادات. هل هناك أي إعدادات يمكنني استخدامها للمساعدة في جمع المزيد من معلومات التشخيص؟

تم إصدار إصدار المطلعين الجدد (http://code.visualstudio.com/Download#insiders) ويتضمن عملنا لعلامات التبويب / المكدسات. يأتي هذا مع التخلص من الموارد بشكل أكثر صرامة لأنه بمجرد إغلاق محرر ، نتخلص من موارده الأساسية.

من الغريب أن يتمكن الأشخاص من الاستضافة الذاتية لهذا لفترة من الوقت والإبلاغ إذا تحسنت الأمور.

ملاحظة: يتم تحديث المطلعين من الآن فصاعدًا كل ليلة (راجع http://code.visualstudio.com/blogs/2016/05/23/evolution-of-insiders)

bpasero لقد قمت بتحديث جميع

نعم ، لقد انتقلت بشكل أساسي إلى المطلعين بسبب المحطة. أوه كم أنا
أحبها. لقد وجدت أن المحرر أكثر أناقة وأخف وزناً. عمل عظيم.

هل هناك أي طريقة يمكنني من خلالها استبدال "الرمز". في سطر الأوامر للإشارة إلى
المطلعين؟

في يوم الأربعاء الموافق 8 يونيو 2016 ، كتب إيليا بات إخطارات github.com:

bpasero https://github.com/bpasero لقد قمت بتحديث جميع أجهزتي اليوم ،
انظر كيف نذهب خلال الأيام القليلة المقبلة

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/508#issuecomment -224539214 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe/AA-JVM4KoGeXoc2SU5VeEYnxkZyPVWYMks5qJo13gaJpZM4Gnvn5
.

لا يزال يحدث عند 1.2.0 بالنسبة لي. يحدث كل ليلة - يعمل على Windows 7 Enterprise SP1. لدي نفس السؤال مثلgarthk

عادة ما أترك الملفات مفتوحة. أنا أركض مع الامتدادات. هل هناك أي إعدادات يمكنني استخدامها للمساعدة في جمع المزيد من معلومات التشخيص؟

n Northerncodemky كنت أشير إلى إصدار المطلعين 1.3.0 حيث يتم تضمين عمل علامات التبويب / المداخن الخاصة بنا (http://code.visualstudio.com/Download#insiders). لا أتوقع أي تغيير كبير في 1.2.0.

bpasero Aah حسنًا - لم

bpasero تبدو جيدة حتى الآن !!

كان لدي VSCode Insiders build يعمل خلال عطلة نهاية الأسبوع. جاء صباح الاثنين وشهدت حادث تحطم.

أتساءل عما إذا كان هناك أي بيانات تعطل / تفريغ للقياس عن بُعد يتم إرسالها تلقائيًا عند تعطل VSCode؟ نوع من مثل تقارير واتسون.

حصلت على آلة جديدة الأسبوع الماضي. عندما أقوم بإعداده ، أضع إصدار الإصدار فقط (وليس المطلعين) - لم ألاحظ أنه يتعطل منذ ذلك الحين.

bpasero لم أر أي أعطال منذ 1.3 ، تشغيل الإصدار الداخلي من Windows 10> = 14367

bpasero مع تفعيل علامات التبويب ، فتح مشروع ac # و vscode يتعطل الخطأ بعد دقيقتين من آخر تحديث لتجزئة الالتزام الداخلي: 5474147bb83618975409dad7d8aa96151d7d1ea1.
ملاحظة: لم أقم سابقًا بتمكين علامات التبويب حتى الآن

@ eByte23 هل يمكنك التحقق من أن هذا مرتبط بتمكين علامات التبويب أم لا عن طريق المحاولة بدون علامات تبويب؟

لا يزال bpasero يحدث عند تعطيل علامات التبويب ، ولكن لا يوجد مكان قريب من الخطورة مع تمكين علامات التبويب.

ولكن يمكن ملاحظته بشكل كبير وقابل للتكرار عند العمل مع الصور ، والنقر بين الصور الكبيرة بسرعة في كل من Insider و v1.2.1

@ eByte23 أقترح فتح مشكلة جديدة حول ذلك بأكبر قدر ممكن من التفاصيل (على سبيل المثال ، هل تنمو الذاكرة؟).

بالتأكيد يمكن أن تفعل. لم أقم بإجراء قدر كبير من التحقيق حوله حتى الآن ، لكنني سأحصل على بعض التفاصيل المتعمقة لك لاحقًا.

يتعطل VSCode 1.3.1 مرتين يوميًا تقريبًا بالنسبة لي ، مرة واحدة بين عشية وضحاها (دائمًا) وأحيانًا بشكل عشوائي أثناء النهار. لقد تحطمت الآن بينما كنت أفتحها في الخلفية ، ولم أستخدمها لمدة ساعتين تقريبًا. أيضًا عند فتح vscode مرة أخرى ، تفقد مساحة العمل الخاصة بي ، ولا بد لي من إعادة فتح مجلد المشروع الذي كان مفتوحًا قبل الانهيار. يتم الاحتفاظ بعلامات التبويب والتقسيمات بعد إعادة فتح المجلد.

تركت مفتوحًا في الخلفية لفترة من الوقت مع التغييرات غير المحفوظة ، وعادت ، وبدأت في الكتابة وتجمد vscode لبضع ثوان ثم تعطلت. لقد فقدت عملي.

آمل أن تتفهم إحباطي. هذا غير مقبول للمحرر. كما أن الجلسة التي تم استعادتها لم يتم فتح علامات التبويب الصحيحة ، ولا مكاني في كل علامة تبويب.

DelvarWorld هل يمكنك مشاركة المزيد من التفاصيل حول بيئة عملك؟ هل يمكنك محاولة التشغيل مع تعطيل الإضافات لمعرفة ما إذا كان ذلك يساعدك؟

لدي نفس هذه المشكلة على Linux Mint 17 Qiana (لا أستطيع تذكر أي إصدار من ubuntu هو!). لقد تجمد بالنسبة لي بعد حوالي ساعتين من عدم النشاط. سأتذكر التحقق من استخدام الذاكرة / وحدة المعالجة المركزية في المرة التالية التي يحدث فيها ذلك ، على الرغم من أنني لم ألاحظ أبدًا تباطؤًا عامًا في التطبيقات الأخرى وما إلى ذلك عند حدوث ذلك.

معلومات VSCode:

الإصدار 1.4.0
الالتزام 6276dcb0ae497766056b4c09ea75be1d76a8b679
التاريخ 2016-08-04T16: 49: 32.489Z
شل 0.37.6
العارض 49.0.2623.75
العقدة 5.10.0

لقد اختفت هذه المشكلة بالنسبة لي (في الإصدار 1.5.3 ، Windows 7) - نظرًا للتعليق الأخير قبل شهرين ، فهل يمكن حل هذه المشكلة؟

لم أر هذا يحدث لي منذ العصور أيضًا. أستخدم الإصدار الحالي منذ شهور. يبدو جيد

نفسه. لا يبدو أنها تفرط على الإطلاق.

حسنًا ، يجب أن نستمر في المشكلات الفردية ونتجنب الأخطاء الوخيمة مثل هذه التي يصعب تتبعها. إذا كان أي شخص لا يزال يرى هذه المشكلة ، يرجى تقديم مشكلات جديدة بمزيد من التفاصيل. يُرجى تجنب اختطاف مشكلة حالية 👍

أتذكر أيضًا أنني رأيت هذا من قبل ولم أره منذ زمن طويل ، لذلك ، هذا هو التحقق الخاص بي.