การแก้ไขข้อบกพร่อง WebAssembly ด้วยเครื่องมือสมัยใหม่

Ingvar Stepanyan

ถนนจนถึงตอนนี้

เมื่อ 1 ปีก่อน Chrome ได้ประกาศการรองรับเบื้องต้นสำหรับการแก้ไขข้อบกพร่อง WebAssembly บนอุปกรณ์ในเครื่องมือสำหรับนักพัฒนาเว็บของ Chrome

เราได้แสดงให้เห็นถึงการสนับสนุน ก้าวเบื้องต้นและพูดคุยเกี่ยวกับโอกาส การใช้ข้อมูล DWARF แทน การแมปแหล่งที่มาจะเปิดให้เราได้ในอนาคต

• การแก้ไขชื่อตัวแปร
• ประเภทการจัดรูปแบบ
• การประเมินนิพจน์ในภาษาต้นฉบับ
• …และอีกมากมาย

วันนี้เรายินดีที่จะได้เผยให้เห็นว่าฟีเจอร์ที่ได้สัญญาไว้จะเข้ามามีชีวิต และความคืบหน้าที่ทีม Emscripten และ Chrome DevTools ได้ดำเนินการ โดยเฉพาะในปีนี้ โดยเฉพาะสำหรับแอปภาษา C และ C++

ก่อนที่จะเริ่ม โปรดทราบว่าฟีเจอร์นี้ยังเป็นรุ่นเบต้า คุณต้องใช้เครื่องมือเวอร์ชันล่าสุดทั้งหมด โดยยอมรับความเสี่ยงเอง และหากคุณประสบปัญหาใดๆ โปรดรายงานปัญหากับ https://issues.chromium.org/issues/new?noWizard=true&template=0&component=1456350.

มาเริ่มด้วยตัวอย่าง C ง่ายๆ เหมือนกับครั้งที่แล้วกัน

#include <stdlib.h>

void assert_less(int x, int y) {
  if (x >= y) {
    abort();
  }
}

int main() {
  assert_less(10, 20);
  assert_less(30, 20);
}

โดยในการรวบรวม เราจะใช้ Escripten ล่าสุด แล้วส่งแฟล็ก -g เช่นเดียวกับในโพสต์ต้นฉบับ เพื่อรวมการแก้ไขข้อบกพร่อง ข้อมูล:

emcc -g temp.c -o temp.html

ตอนนี้เราสามารถแสดงหน้าเว็บที่สร้างขึ้นจากเซิร์ฟเวอร์ HTTP ของ localhost (เช่น ด้วย serve) และเปิดหน้าเว็บใน Chrome Canary เวอร์ชันล่าสุดได้แล้ว

ครั้งนี้เราจำเป็นต้องมีส่วนขยายตัวช่วยที่ผสานรวมกับ Chrome เครื่องมือสำหรับนักพัฒนาเว็บและช่วยให้เข้าใจข้อมูลการแก้ไขข้อบกพร่องทั้งหมด ที่เข้ารหัสในไฟล์ WebAssembly โปรดติดตั้งโดยไปที่ ลิงก์นี้: goo.gle/wasm-debugging-extension

คุณจะต้องเปิดใช้การแก้ไขข้อบกพร่อง WebAssembly ในเครื่องมือสำหรับนักพัฒนาเว็บด้วย การทดสอบ เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คลิกไอคอนรูปเฟือง (⚙) ใน ที่มุมขวาบนของแผงเครื่องมือสำหรับนักพัฒนาเว็บ ให้ไปที่แผงการทดสอบ แล้วเลือกการแก้ไขข้อบกพร่อง WebAssembly: เปิดใช้การสนับสนุน DWARF

เมื่อปิดการตั้งค่า เครื่องมือสำหรับนักพัฒนาเว็บจะแนะนำให้โหลดซ้ำเพื่อใช้การตั้งค่า ดังนั้นเรามาลองทำกัน และจบลงเพียงเท่านี้ การตั้งค่า

ตอนนี้เรากลับไปที่แผงแหล่งที่มา เปิดใช้หยุดชั่วคราวเมื่อพบข้อยกเว้น (ไอคอน ⏸) จากนั้นเลือกหยุดชั่วคราวเมื่อพบข้อยกเว้น แล้วโหลดหน้าเว็บซ้ำ คุณควรเห็นเครื่องมือสำหรับนักพัฒนาเว็บหยุดชั่วคราวในข้อยกเว้น

โดยค่าเริ่มต้น เครื่องมือจะหยุดที่โค้ดกาวที่ Emscripten สร้างขึ้น แต่คุณจะเห็นมุมมองสแต็กการเรียกทางด้านขวา ซึ่งแสดงสแต็กเทรซของข้อผิดพลาด และไปยังบรรทัด C เดิมที่เรียกใช้abortได้

ตอนนี้ หากคุณดูในมุมมองขอบเขต คุณจะเห็นชื่อเดิมและค่าของตัวแปรในโค้ด C/C++ และไม่ต้องพยายามหาความหมายของชื่อที่ตัดตอนมา เช่น $localN และความสัมพันธ์กับซอร์สโค้ดที่คุณเขียนอีกต่อไป

การดำเนินการนี้ไม่เพียงใช้กับค่าพื้นฐาน เช่น จํานวนเต็ม แต่ยังใช้กับประเภทแบบผสม เช่น โครงสร้าง คลาส อาร์เรย์ และอื่นๆ ด้วย

การสนับสนุนประเภทริชมีเดีย

มาดูตัวอย่างที่ซับซ้อนขึ้นเพื่อแสดงให้เห็นกรณีดังกล่าว ช่วงเวลานี้ เราจะวาดแฟร็กทัล Mandelbrot ด้วย รหัส C++ ต่อไปนี้

#include <SDL2/SDL.h>
#include <complex>

int main() {
  // Init SDL.
  int width = 600, height = 600;
  SDL_Init(SDL_INIT_VIDEO);
  SDL_Window* window;
  SDL_Renderer* renderer;
  SDL_CreateWindowAndRenderer(width, height, SDL_WINDOW_OPENGL, &window,
                              &renderer);

  // Generate a palette with random colors.
  enum { MAX_ITER_COUNT = 256 };
  SDL_Color palette[MAX_ITER_COUNT];
  srand(time(0));
  for (int i = 0; i < MAX_ITER_COUNT; ++i) {
    palette[i] = {
        .r = (uint8_t)rand(),
        .g = (uint8_t)rand(),
        .b = (uint8_t)rand(),
        .a = 255,
    };
  }

  // Calculate and draw the Mandelbrot set.
  std::complex<double> center(0.5, 0.5);
  double scale = 4.0;
  for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {
      std::complex<double> point((double)x / width, (double)y / height);
      std::complex<double> c = (point - center) * scale;
      std::complex<double> z(0, 0);
      int i = 0;
      for (; i < MAX_ITER_COUNT - 1; i++) {
        z = z * z + c;
        if (abs(z) > 2.0)
          break;
      }
      SDL_Color color = palette[i];
      SDL_SetRenderDrawColor(renderer, color.r, color.g, color.b, color.a);
      SDL_RenderDrawPoint(renderer, x, y);
    }
  }

  // Render everything we've drawn to the canvas.
  SDL_RenderPresent(renderer);

  // SDL_Quit();
}

คุณจะเห็นได้ว่าแอปพลิเคชันนี้ยังมีค่อนข้างเล็กอยู่ แต่เป็นการโหลดที่ ที่มีโค้ด 50 บรรทัด แต่คราวนี้ฉันใช้ API ภายนอก เช่น ไลบรารี SDL สำหรับ รวมไปถึงจำนวนเชิงซ้อนจาก C++ ไลบรารีมาตรฐาน

ผมจะคอมไพล์ด้วย Flag -g เดียวกับด้านบนเพื่อรวม ข้อมูลการแก้ไขข้อบกพร่อง และฉันจะขอให้ Emscripten ระบุ SDL2 ด้วย และอนุญาตหน่วยความจำขนาดใดก็ได้ตามต้องการ

emcc -g mandelbrot.cc -o mandelbrot.html \
     -s USE_SDL=2 \
     -s ALLOW_MEMORY_GROWTH=1

เมื่อฉันเข้าชมหน้าเว็บที่สร้างขึ้นในเบราว์เซอร์ ก็จะเห็น รูปร่างแบบแฟร็กทัลที่มีสีแบบสุ่มบางส่วน:

เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บอีกครั้ง ฉันก็เห็นไฟล์ C++ ต้นฉบับ ช่วงเวลานี้ อย่างไรก็ตาม เราไม่พบข้อผิดพลาดในโค้ด (ว้าว!) ดังนั้นมาลองตั้งค่า เบรกพอยท์บางส่วนที่จุดเริ่มต้นของโค้ดแทน

เมื่อเราโหลดหน้าเว็บซ้ำ โปรแกรมแก้ไขข้อบกพร่องจะหยุดชั่วคราวในซอร์สโค้ด C++ ของเรา

เราเห็นตัวแปรทั้งหมดทางด้านขวาแล้ว แต่ตอนนี้มีเพียง width และ height เท่านั้นที่เริ่มต้นแล้ว จึงไม่มีอะไรให้ตรวจสอบมากนัก

มาตั้งจุดหยุดชั่วคราวอีกจุดหนึ่งในลูป Mandelbrot หลัก แล้วดำเนินการต่อเพื่อข้ามไปข้างหน้าสักหน่อย

ตอนนี้ palette ของเราเต็มไปด้วยสีแบบสุ่ม และเราสามารถขยายทั้งอาร์เรย์และ SDL_Color และตรวจสอบส่วนประกอบต่างๆ เพื่อยืนยันว่า ทุกอย่างดูดีแล้ว (ตัวอย่างเช่น มีการตั้งค่าช่อง "อัลฟ่า" เสมอ เป็นความทึบแสงสูงสุด) ในทํานองเดียวกัน เราสามารถขยายและตรวจสอบส่วนจริงและส่วนจินตภาพของจํานวนเชิงซ้อนที่จัดเก็บไว้ในตัวแปร center

หากคุณต้องการเข้าถึงพร็อพเพอร์ตี้ที่ฝังลึก ซึ่งยากต่อการเข้าถึง ผ่านมุมมองขอบเขต คุณสามารถใช้คอนโซล การประเมินด้วยเช่นกัน อย่างไรก็ตาม โปรดทราบว่าระบบยังไม่รองรับนิพจน์ C++ ที่ซับซ้อนมากขึ้น

มาลองดำเนินการอีกครั้งสัก 2-3 ครั้งแล้วจะได้เห็นว่า x ภายใน ได้เช่นกันโดยดูในมุมมองขอบเขตอีกครั้ง การเพิ่ม ลงในรายการเฝ้าดู ประเมินตัวแปรในคอนโซล หรือโดย เมื่อวางเมาส์เหนือตัวแปรในซอร์สโค้ด

จากตรงนี้ เราสามารถตรวจสอบคำสั่ง C++ หรือขั้นตอน ตัวแปรอื่นๆ ก็เปลี่ยนแปลงเช่นกัน:

ทุกอย่างเรียบร้อยดีเมื่อมีข้อมูลการแก้ไขข้อบกพร่อง แต่ จะทำอย่างไรถ้าเราต้องการดีบักโค้ดที่ไม่ได้สร้างมากับการแก้ไขข้อบกพร่อง ตัวเลือกเพิ่มเติม

การแก้ไขข้อบกพร่อง WebAssembly แบบ Raw

ตัวอย่างเช่น เราขอให้ Emscripten จัดหาไลบรารี SDL ที่คอมไพล์ไว้ล่วงหน้าให้เราใช้แทนการคอมไพล์จากซอร์สโค้ดด้วยตนเอง ดังนั้นอย่างน้อยก็ในตอนนี้ โปรแกรมแก้ไขข้อบกพร่องจะหาแหล่งที่มาที่เกี่ยวข้องไม่ได้ เรามาดูรายละเอียดของ SDL_RenderDrawColor อีกครั้งกัน

เรากลับมาที่การแก้ไขข้อบกพร่อง WebAssembly แบบข้อมูลดิบ

ตอนนี้มันดูน่ากลัวสักหน่อย และไม่ใช่สิ่งที่นักพัฒนาเว็บส่วนใหญ่จะทำ ที่ต้องจัดการ แต่บางครั้งคุณอาจต้องแก้ไขข้อบกพร่อง ไลบรารีที่สร้างขึ้นโดยไม่มีข้อมูลการแก้ไขข้อบกพร่อง ไม่ว่าจะเป็นเพราะ ไลบรารี^{ของบุคคลที่สาม}ที่คุณไม่มีสิทธิ์ควบคุม หรือเนื่องจากคุณ ข้อบกพร่องที่เกิดขึ้นเฉพาะในเวอร์ชันที่ใช้งานจริงเท่านั้น

เราได้ปรับปรุงประสบการณ์การแก้ไขข้อบกพร่องขั้นพื้นฐานด้วยเพื่อช่วยเหลือในเคสเหล่านี้

ก่อนอื่น หากคุณเคยใช้การแก้ไขข้อบกพร่อง WebAssembly แบบข้อมูลดิบมาก่อน คุณอาจ ให้สังเกตว่าการถอดแยกชิ้นส่วนทั้งหมดแสดงอยู่ในไฟล์เดียวคือ เดาได้มากขึ้นว่าฟังก์ชันใดในรายการแหล่งที่มาที่ wasm-53834e3e/ wasm-53834e3e-7 อาจสอดคล้อง

รูปแบบการสร้างชื่อใหม่

นอกจากนี้ เรายังปรับปรุงชื่อในมุมมองการถอดชิ้นส่วนด้วย ก่อนหน้านี้คุณจะเห็นเฉพาะดัชนีตัวเลข หรือในกรณีที่เป็นฟังก์ชัน จะไม่มีชื่อเลย

ตอนนี้เราสร้างชื่อในลักษณะเดียวกับเครื่องมือถอดประกอบอื่นๆ โดยจะใช้คำแนะนำจากส่วนชื่อ WebAssembly, เส้นทางการนำเข้า/ส่งออก และสุดท้าย หากวิธีอื่นๆ ทั้งหมดไม่ได้ผล เราจะสร้างชื่อตามประเภทและดัชนีของรายการ เช่น $func123 คุณจะเห็นในภาพหน้าจอด้านบนว่าการดำเนินการนี้ช่วยให้สแต็กเทรซและการถอดประกอบอ่านได้ง่ายขึ้นเล็กน้อย

เมื่อไม่มีข้อมูลประเภท คุณอาจตรวจสอบค่าอื่นๆ นอกเหนือจากค่าพื้นฐานได้ยาก เช่น ตัวชี้จะแสดงเป็นจำนวนเต็มปกติ โดยไม่มีวิธีที่จะทราบว่ามีอะไรจัดเก็บอยู่เบื้องหลังในหน่วยความจำ

การตรวจสอบหน่วยความจำ

ก่อนหน้านี้ คุณจะขยายได้เฉพาะออบเจ็กต์หน่วยความจำ WebAssembly ซึ่งแสดงด้วย env.memory ในมุมมองขอบเขตเพื่อค้นหา แต่ละไบต์ วิธีนี้ใช้ได้ในบางสถานการณ์ที่ไม่ซับซ้อน แต่ขยายผลได้ไม่ค่อยสะดวกนักและไม่อนุญาตให้ตีความข้อมูลในรูปแบบอื่นนอกเหนือจากค่าไบต์ เราได้เพิ่มฟีเจอร์ใหม่เพื่อช่วยแก้ปัญหานี้ด้วยเช่นกัน ซึ่งก็คือเครื่องมือตรวจสอบหน่วยความจำแบบเชิงเส้น

หากคลิกขวาที่ env.memory คุณจะเห็น ตัวเลือกที่ชื่อว่าตรวจสอบหน่วยความจำ

เมื่อคลิกแล้ว ระบบจะแสดงเครื่องมือตรวจสอบหน่วยความจำ ซึ่งคุณสามารถตรวจสอบหน่วยความจำ WebAssembly ในมุมมองฐาน 16 และ ASCII ไปยังที่อยู่ที่ต้องการ รวมถึงตีความข้อมูลในรูปแบบต่างๆ ได้ ดังนี้

สถานการณ์และคำเตือนขั้นสูง

การทำโปรไฟล์โค้ด WebAssembly

เมื่อเปิดเครื่องมือสำหรับนักพัฒนาเว็บ โค้ด WebAssembly จะ "ปรับลง" เป็น เวอร์ชันที่ไม่ได้เพิ่มประสิทธิภาพเพื่อให้เปิดใช้การแก้ไขข้อบกพร่อง เวอร์ชันนี้จะช้ากว่ามาก ซึ่งหมายความว่าคุณไม่สามารถใช้ console.time, performance.now และวิธีการอื่นๆ ในการวัดความเร็วของโค้ดขณะที่เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์เปิดอยู่ เนื่องจากตัวเลขที่คุณได้รับจะไม่แสดงถึงประสิทธิภาพจริง

คุณควรใช้แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์แทน ซึ่งจะเรียกใช้โค้ดด้วยความเร็วเต็มที่และแสดงรายละเอียดเกี่ยวกับเวลาที่ใช้ในการดำเนินการต่างๆ ของฟังก์ชันต่างๆ ดังนี้

หรือคุณสามารถเรียกใช้แอปพลิเคชันโดยปิดเครื่องมือสำหรับนักพัฒนาเว็บ และ ให้เปิดหน้าเมื่อเสร็จสิ้นเพื่อตรวจสอบคอนโซล

เราจะปรับปรุงสถานการณ์การทำโปรไฟล์ในอนาคต แต่สำหรับตอนนี้ ข้อควรระวัง หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับ WebAssembly สถานการณ์การแบ่งระดับ โปรดดูเอกสารของเราในไปป์ไลน์การคอมไพล์ WebAssembly

การสร้างและการแก้ไขข้อบกพร่องในเครื่องต่างๆ (รวมถึง Docker / โฮสต์)

เมื่อสร้างใน Docker, เครื่องเสมือน หรือเซิร์ฟเวอร์บิลด์ระยะไกล คุณอาจพบกรณีที่เส้นทางไปยังไฟล์ต้นฉบับที่ใช้ในระหว่างการสร้างไม่ตรงกับเส้นทางในระบบไฟล์ของคุณเองที่เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome ทำงานอยู่ ในกรณีนี้ ไฟล์จะปรากฏในแผงแหล่งที่มาแต่โหลดไม่สำเร็จ

เราได้ติดตั้งใช้งานฟังก์ชันการแมปเส้นทางใน ตัวเลือกส่วนขยาย C/C++ คุณสามารถใช้เพื่อแมปเส้นทางที่กำหนดเองใหม่และช่วยเครื่องมือสำหรับนักพัฒนาเว็บค้นหาแหล่งที่มาได้

ตัวอย่างเช่น หากโปรเจ็กต์ในเครื่องโฮสต์อยู่ภายใต้เส้นทาง C:\src\my_project แต่สร้างขึ้นภายในคอนเทนเนอร์ Docker ที่แสดงเส้นทางนั้นเป็น /mnt/c/src/my_project คุณจะแมปเส้นทางนั้นกลับได้ในระหว่างการแก้ไขข้อบกพร่องโดยระบุเส้นทางเหล่านั้นเป็นคำนำหน้า ดังนี้

คำนำหน้าแรกที่ตรงกันจะ "ชนะ" หากคุณคุ้นเคยกับโปรแกรมแก้ไขข้อบกพร่อง C++ อื่นๆ ตัวเลือกนี้จะคล้ายกับคำสั่ง set substitute-path ใน GDB หรือการตั้งค่า target.source-map ใน LLDB

การแก้ไขข้อบกพร่องของบิลด์ที่เพิ่มประสิทธิภาพ

การแก้ไขข้อบกพร่องจะทํางานได้ดีที่สุดเมื่อปิดใช้การเพิ่มประสิทธิภาพ เช่นเดียวกับภาษาอื่นๆ การเพิ่มประสิทธิภาพอาจรวมฟังก์ชันหนึ่งไว้ในอีกฟังก์ชันหนึ่ง จัดเรียงโค้ดใหม่ หรือนําโค้ดบางส่วนออกทั้งหมด ซึ่งทั้งหมดนี้มีโอกาสที่จะทำให้โปรแกรมแก้ไขข้อบกพร่องสับสน และส่งผลต่อคุณในฐานะผู้ใช้ด้วย

หากไม่สนใจประสบการณ์การแก้ไขข้อบกพร่องที่จำกัดมากขึ้นและยังคงต้องการแก้ไขข้อบกพร่องของบิลด์ที่เพิ่มประสิทธิภาพแล้ว การเพิ่มประสิทธิภาพส่วนใหญ่จะทำงานตามที่คาดไว้ ยกเว้นการฝังฟังก์ชัน เราวางแผนที่จะแก้ไขปัญหาที่เหลือในอนาคต แต่ในระหว่างนี้ โปรดใช้ -fno-inline เพื่อปิดใช้เมื่อคอมไพล์ด้วยการเพิ่มประสิทธิภาพระดับ -O เช่น

emcc -g temp.c -o temp.html \
     -O3 -fno-inline

การแยกข้อมูลการแก้ไขข้อบกพร่อง

ข้อมูลการแก้ไขข้อบกพร่องจะเก็บรายละเอียดมากมายเกี่ยวกับโค้ดของคุณ ประเภท ตัวแปร ฟังก์ชัน ขอบเขต และตำแหน่ง-ทุกสิ่งที่อาจ ที่เป็นประโยชน์สำหรับโปรแกรมแก้ไขข้อบกพร่องได้ ด้วยเหตุนี้ ไฟล์นี้จึงมักมีขนาดใหญ่กว่าโค้ด

หากต้องการให้โหลดและคอมไพล์โมดูล WebAssembly เร็วขึ้น คุณอาจ ต้องการแยกข้อมูลการแก้ไขข้อบกพร่องนี้เป็น WebAssembly แยกต่างหาก หากต้องการดำเนินการดังกล่าวใน Emscripten ให้ส่ง Flag -gseparate-dwarf=… พร้อมชื่อไฟล์ที่ต้องการ ดังนี้

emcc -g temp.c -o temp.html \
     -gseparate-dwarf=temp.debug.wasm

ในกรณีนี้ แอปพลิเคชันหลักจะจัดเก็บเฉพาะชื่อไฟล์ temp.debug.wasm ส่วนส่วนขยายตัวช่วยจะค้นหาและโหลดไฟล์ได้เมื่อคุณเปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์

เมื่อใช้ร่วมกับการเพิ่มประสิทธิภาพตามที่อธิบายไว้ข้างต้น ฟีเจอร์นี้ยังใช้เพื่อจัดส่งบิลด์เวอร์ชันที่ใช้งานจริงซึ่งเกือบจะเพิ่มประสิทธิภาพแล้วของแอปพลิเคชัน และแก้ไขข้อบกพร่องในภายหลังด้วยไฟล์ฝั่งอุปกรณ์ได้ด้วย ในกรณีนี้ เรายังจะต้องลบล้าง URL ที่จัดเก็บไว้เพื่อช่วยให้ส่วนขยาย ค้นหาไฟล์ด้านข้าง เช่น

emcc -g temp.c -o temp.html \
     -O3 -fno-inline \
     -gseparate-dwarf=temp.debug.wasm \
     -s SEPARATE_DWARF_URL=file://[local path to temp.debug.wasm]

โปรดติดตามต่อ…

ว้าว ฟีเจอร์ใหม่เยอะมากเลย

การผสานรวมใหม่ทั้งหมดนี้ทำให้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome กลายเป็นโปรแกรมแก้ไขข้อบกพร่องที่มีประสิทธิภาพและใช้งานได้จริง ไม่ใช่แค่สำหรับ JavaScript เท่านั้น แต่ยังใช้กับแอป C และ C++ ได้ด้วย ซึ่งทำให้การนำแอปที่สร้างขึ้นด้วยเทคโนโลยีที่หลากหลายไปใช้ในเว็บแบบข้ามแพลตฟอร์มที่แชร์กันเป็นเรื่องง่ายกว่าที่เคย

อย่างไรก็ตาม เส้นทางของเรายังไม่สิ้นสุด สิ่งที่เราจะเปลี่ยนแปลง ดำเนินการต่อไป จากนี้:

• ปรับปรุงประสบการณ์การแก้ไขข้อบกพร่อง
• การเพิ่มการรองรับตัวจัดรูปแบบประเภทที่กำหนดเอง
• กำลังปรับปรุงการโปรไฟล์สําหรับแอป WebAssembly
• เพิ่มการรองรับการครอบคลุมโค้ดเพื่อให้ค้นหาโค้ดที่ไม่ได้ใช้งานได้ง่ายขึ้น
• ปรับปรุงการรองรับนิพจน์ในการประเมินคอนโซล
• เพิ่มการรองรับภาษาอื่นๆ
• …และอีกมากมาย

ในระหว่างนี้ โปรดช่วยเราด้วยการลองใช้รุ่นเบต้าเวอร์ชันปัจจุบันด้วยโค้ดของคุณเอง แล้วรายงานปัญหาที่พบ ออกให้กับ https://issues.chromium.org/issues/new?noWizard=true&template=0&component=1456350.

ดาวน์โหลดแชแนลตัวอย่าง

ลองใช้ Chrome Canary, Dev หรือ เบต้า เป็นเบราว์เซอร์เริ่มต้นสำหรับการพัฒนา ช่องทางพรีวิวเหล่านี้จะช่วยให้คุณเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และพบปัญหาในเว็บไซต์ก่อนผู้ใช้

ติดต่อทีม Chrome DevTools

ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์และการเปลี่ยนแปลงใหม่ๆ ในโพสต์ หรือสิ่งอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ

• ส่งข้อเสนอแนะหรือความคิดเห็นถึงเราทาง crbug.com
• รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม     > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
• ทวีตที่ @ChromeDevTools
• แสดงความคิดเห็นในมีอะไรใหม่ในวิดีโอ YouTube เกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บ หรือวิดีโอ YouTube เคล็ดลับสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ