ওয়েট বাশ-বিল্টিন 100 শতাংশে সিপিইউ বার্ন করে


16

কমপক্ষে GNU ব্যাশ সংস্করণ 4.3.42 x86_64 && NNG বাশ সংস্করণ 4.3.11 x86_64 এ দেখা যায়

আমি একটি সিগন্যাল ( সিগুসআর 1 হিসাবে ) দ্বারা বাধাপ্রাপ্ত হওয়ার জন্য সাধারণেরsleep & wait $! পরিবর্তে ব্যবহার করি । তবে মনে হয় যে নিম্নলিখিতটি চালানোর সময় ব্যাশ-বিল্টিন একটি অদ্ভুত আচরণ করে।sleepsleepwait

বন্দর 1:

cat <(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
   )&

টার্মিনাল ২:

kill -10 /the pid of the subshell, printed by the previous command/

বন্দর 1:

^C (ctrl + C)

তারপরে, আমি একটি সাবসিএল পেয়ে যা 100 শতাংশে সিপিইউ পোড়ায়।

বন্দর 1:

pkill -P $(pgrep -P $$)

কেন এই আচরণ ঘটে তা সম্পর্কে আপনার কোনও ধারণা আছে?

এনবি : cat <(/subshell/)ব্যাকগ্রাউন্ডে না থাকলে কোনও সমস্যা হয় না।


এই আচরণটি অনুভব করার আরেকটি উপায়

বন্দর 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)&

টার্মিনাল ২:

kill -10 /the pid of the subshell, printed by the previous command/

বন্দর 1:

fg
^C (ctrl + C)

তারপরে, হিমায়িত শেলটি পান।


এই আচরণটি অভিজ্ঞতার তৃতীয় উপায়

বন্দর 1:

(
   trap 'echo SIGUSR1' SIGUSR1;
   echo $BASHPID;
   while :;do
       sleep 1 &
       wait $!;
       echo test;
   done
)

টার্মিনাল ২:

kill -10 /the pid of the subshell, printed by the previous command/

বন্দর 1:

^C (ctrl + C)

তারপরে, হিমায়িত শেলটি পান।


এটি ডিবাগ করার জন্য, আপনাকে সম্ভবত উত্স থেকে বাশ তৈরি করতে হবে এবং এটি কোথায় লুপ করছে তা খুঁজে বের করতে হবে (এটি একটি ডিবাগার দিয়ে ভেঙে ফেলুন বা মুদ্রণ বিবৃতি যুক্ত করুন) এবং কেন এটি লুপ হচ্ছে op
কাজ

1
স্ট্রেঞ্জ? আমি এখানে এটি পুনরুত্পাদন করতে পারি না, আমি ব্যাশ 4.3.42 (1) -রিলেজ (x86_64-pc-linux-gnu) ব্যবহার করছি। ডেবিয়ান 8. কার্নেল 4.6.1-1। আপনারা বলছেন এমন সমস্ত পরীক্ষাগুলি আমি করি তবে সিপিইউ এখনও স্বাভাবিকভাবে চলমান ... আপনি fg এবং CTRL + C সহ ঠিক যেমনটি বলছেন ঠিক তেমনই করছি।
লুসিয়ানো অ্যান্ড্রেস মার্টিনি

আমার মনে আছে যে বিল্ট-ইনগুলি এবং সংকেত সম্পর্কিত কিছু জিনিস bash4.4 -এ পরিবর্তিত হয়েছে , সম্ভবত এটি এখানে প্রভাবিত হতে পারে।
phk

4.4.20 বাশ এটির সাথেwait খুব সাদৃশ্যপূর্ণ এমন একটি স্পিনলুপ ইস্যুটি ঠিক করে । আমি চূড়ান্তভাবে উপ-প্রক্রিয়া তৈরি করে এমন একটি লুপে আমার দ্বারা আঘাতিত হয়েছিল। যাইহোক, আমি আপনার পরিস্থিতি 4.4.20 এ পরীক্ষা করেছি এবং এটি এখনও একটি সমস্যা ছিল। মজার ব্যাপার হচ্ছে, যখন আমি একটি সংস্করণ আমার নির্মিত একটি ডিবাগার সংযুক্ত, আমি দেখতে পারে এটি প্রায় লুপিং হয়েছিল, কিন্তু এটা এছাড়াও বাইরে ভঙ্গ প্রভাব ছিল, এবং লুপ আবার 'পরীক্ষা' outputting শুরু করবে। অন্য কথায়: ডিবাগার সংযুক্তি এটি স্পিনলুপিং বন্ধ করে দেয়।
হাফগ্গার

উত্তর:


1

পর্যবেক্ষণ

  • ctrl+cSIGINTটার্মিনাল 1 এ fg- প্রসেসে প্রেরণ করে
  • অত: পর, নির্বাহ kill -2 <PID>টার্মিনাল 2 আঘাত হিসাবে একই ctrl+cTerminal 1
  • টার্মিনাল 2 এ কার্যকর করার আগে উপরের দুটি পয়েন্টগুলির একটি kill -10 <PID>করে SIGINTসঠিকভাবে পরিচালনা করে doing
  • টার্মিনাল 2 (সিগন্যাল প্রেরণ ) এ কার্যকর করার পরে এটি সঠিকভাবে পরিচালনা করে না এবং সমস্যাযুক্ত আচরণের দিকে পরিচালিত করেkill -10 <PID>SIGUSR1SIGINT
  • প্রতিস্থাপন করা হচ্ছে kill -2 <PID>টার্মিনাল 2 (মধ্যে SIGINT) সঙ্গে kill -15 <PID>( SIGTERM) অথবা kill -9 <PID>( SIGKILLসঠিক সংকেত হ্যান্ডলিং সবসময়) বাড়ে।
  • নির্বাহ kill -10 <PID>টার্মিনাল 2 বিঘ্নিত waitbuiltin কিন্তু যেহেতু লুপ ছাড়বে না testপরে সংকেত অবিলম্বে printet হয় SIGUSR1আটকা পড়ে যায় এবং লুপ চলতে থাকে।
  • SIGINTএক্সিকিউটিভ লুপ থেকে বিরতি প্রেরণ এবং শেলটি waitহিমশীতল করে বা এটি কখনও বাধা দেয় না এবং অপেক্ষা / হিমায়িত থাকে না ।

উপসংহার

SIGINTসঠিকভাবে চাওয়া এবং পরিচালনা করা হয় না বা ম্যানুয়ালি ট্র্যাপিংয়ের পরে SIGUSR1বা অন্য কোনও ব্যবহারকারীর দ্বারা নির্ধারিত ট্র্যাপিংয়ের পরে তা উপেক্ষা করা হয় । এর অর্থ এই প্রক্রিয়াটি এখনও বিদ্যমান এবং সে কারণেই এটি সিপিইউ খায় / উত্তাপ দেয় বা শেলটি হিমশীতল করে। টার্মিনাল 2 কার্যকর করা kill -15 <PID>বা kill -9 <PID>থেকে প্রক্রিয়াটি সমাপ্ত / নিহত করে এবং আপনাকে টার্মিনাল 1 এর নিয়ন্ত্রণ ফিরিয়ে দেয় এবং আপনার সিপিইউ শিথিল করে।

কেন এই সমস্যা দেখা দেয়, এখনও একটি রহস্য রয়ে গেছে, তবে আমি আশা করি যে পর্দার পিছনে আসলে কী ঘটছে তা কেউ সঠিকভাবে ব্যাখ্যা করতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.