タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
調べようと思ったきっかけは、golang では以下のように ローカル変数のアドレスを戻り値としても問題ないということ。 package main import ( "fmt" ) type Animal struct { Name string Age int } func main() { animal := allocAnimal() fmt.Printf("allocate animal structure %p", animal) } func allocAnimal() *Animal { return &Animal{} } C/C++ ではローカル変数のポインタを戻り値とした場合、 スタック領域のポインタを関数外に渡してしまうため、コンパイル時点で警告が表示されます (なぜエラーにしない) 実行時には最悪、セグメンテーションフォールトで落ちます そのため、malloc や n
アルゴリズム図鑑 絵で見てわかる26のアルゴリズム 作者:石田保輝,宮崎修一翔泳社Amazon アルゴリズム図鑑を眺めていて、二分ヒープ構造は優先度付きキューに使われることを知った。面白いなーと思うと同時に、そういえば二分ヒープ構造の実装をしたことがなく、あまり理解できていないことに気づいた。そこで簡単にRubyで実装をしてみたのでメモ。簡単なテストケースを作ったので多分合ってると思うけど、もしかしたらバグっているかも... 二分ヒープの詳細は二分ヒープ - Wikipediaも参考。 【2023/01/03 14:01追記】要素数が1の時に要素が空にならないバグがあったので修正しました。コメントありがとうございます。https://github.com/shibayu36/algorithms/commit/6c2ce588f7bc7fb890c6a560c7ab062c6f531a9a
本連載では、Javaプログラムの実行を担うJava仮想マシン（JVM）について、その情報を取得するさまざまなツールの利用を通じて理解を深めます。JVMやそのツールに関する知識はアプリケーションが正常に動作しているときではなく、障害など異常が起こった際に大いに活躍します。それだけでなく、Javaプログラムを動作させる仕組みを知ることはソフトウェアを開発するエンジニアの皆さんの知的な部分を刺激するとともに、シニアレベルのJavaエンジニアへと進む第一歩となります。連載第1回はJVMの概要を解説し、模擬的なトラブルシュート体験としてヒープダンプを取得して解析します。 はじめに 今後もアプリケーションをJavaで開発、運用していくことを前提にすると、そうした業務に携わる方は次のようなことを学び続けるでしょう。 Javaの半年ごとのバージョンアップに追随して新機能などを学ぶ アーキテクチャなどでの新
引数は6つありますが、ここで大事なのは、recvfrom関数ではソケットを通じてデータを受信する際に、第2引数で指定したバッファに対し、第3引数で指定したサイズでデータを受信して格納するということです。リスト1では、第2引数で指定しているバッファはstate->rpacket.dataで、第3引数で指定しているデータサイズはstate->blksize + 4です。 では、このバッファはいったいどこで確保されているのでしょうか？ そして受信するデータサイズは、どのようにしてstate->blksizeに指定されているのでしょうか？ オーバーフローするバッファ 解析した結果、同じくtftp.cの中のtftp_connect関数内で、このバッファが確保されていることがわかりました（リスト3）。具体的には、指定したバイト分のメモリを指定個分だけ確保するcalloc関数を利用してblksize
ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) です。以前、ESP-IDF v4.3でヒープ残量が10KB減る問題の調査内容について書きました。 engineering.nature.global そして舌の根も乾かぬうちにESP-IDF v4.4で再びヒープ残量が4KBも減ることに気づき、その調査を行いました。 結論だけ最初に書いておくと、BluetoothがHigh Level Interruptを使うようになり、そのスタックとして静的に4KBを割り当てるようになっています。High Level Interruptを使うかどうかはコンフィグで切り替え可能なのですが、Bluetoothのバグフィックスやパフォーマンス向上をしているため、Bluetoothを使用する場合は甘んじて4KBのメモリをESP-IDFに捧げるのが良さそうです。 発端 先週 (2
はじめに こんにちは。私は弊社で企画・運営している、Dot to Dotという個人の同意の元に様々なデータを連携することができる分散型データ連携プラットフォームの開発・保守を担当しています。 Dot to Dotではデータ連携をしたい事業者向けに、データ連携用の通信モジュールを、Spring Bootを使用したJavaアプリケーションとして作成したDockerイメージ形式で配布しています。 昨今ではDockerでアプリケーションを実行するのが当たり前の風潮になりつつありますが、実際に本番で適用する際に必要なチューニングの話はあまり聞かないかと思います。 そこで本記事では、JavaアプリケーションをDockerコンテナで運用する場合に必要な、ヒープのチューニングについて説明します。これからJavaアプリケーションをDockerコンテナ化して運用したい人や、すでに運用中でもヒープチューニングし
サイバーエージェントのゲーム・エンターテイメント事業部（SGE）に所属する子会社QualiArtsでUnityエンジニアをしている篠木です。本記事はQualiArtsの定期ブログ「QualiArts Tech Note」第12弾の記事となります。QualiArtsでは会社で使われている様々な技術の知見をブログで紹介しています。興味のある方は、QualiArtsとタグの付いている他の記事もチェックしてみてください。 QualiArts Tech Note この記事について この記事ではGC Allocation（以下、メモリ確保）が行われるパターンとその詳細について書いています。軽いメモリ周りの知識がある前提で書いているので、もし知らない方や不安がある方がいましたら、そちらから調べてみるのをおすすめします。個人的にはこちらの記事が分かり易くまとまっているのでおすすめです。メモリ周りの知識に不
JPCERT-AT-2022-0032 JPCERT/CC 2022-12-13（新規） 2022-12-19（更新） I. 概要2022年12月12日（現地時間）、FortinetはFortiOS SSL-VPNにおけるヒープベースのバッファーオーバーフローの脆弱性（CVE-2022-42475）に関するアドバイザリ（FG-IR-22-398）を公開しました。本脆弱性が悪用されると、認証されていない遠隔の第三者が、細工したリクエストを送信し、任意のコードやコマンドを実行する可能性があります。 Fortinet FortiOS - heap-based buffer overflow in sslvpnd https://www.fortiguard.com/psirt/FG-IR-22-398 Fortinetは、本脆弱性を悪用する攻撃を確認しています。影響を受ける製品を利用している場合
sudo バージョン 1.8.2 から 1.8.31p2 sudo バージョン 1.9.0 から 1.9.5p1 本脆弱性の影響を受けるディストリビューションについては、各ディストリビュータが公開する情報を参照してください。 sudo にはコマンドの引数に設定された特殊文字のエスケープ処理の実装に起因した、ヒープベースのバッファオーバーフロー (CWE-122) の脆弱性が存在します。 2021年2月5日時点において、macOS、AIX、Solaris においても影響を受ける可能性があるとの報告がされていますが、発見者による確認は実施されていません。 なお、2021年2月9日に Apple から本件に対応するセキュリティアップデートが公開されました。
ヒープ領域とは、動的に確保と解放を繰り返せるメモリ領域のことです。プログラムの実行時には、OSからソフトウェアに対して一定量のヒープ領域が与えられます。ソフトウェアは、必要に応じて任意にヒープ領域を確保・解放できます。 ヒープ領域はデータの仮置き場や、臨時の作業台のような存在といえるでしょう。基本的に利用し終わった領域は解放し、再び自由に使える状態にしておきます。 なお、ツリー状のデータ構造のこともヒープと呼びますが、それとは意味が異なるため気をつけましょう。またプログラミング言語によってヒープの意味が異なる場合もあります。たとえば、javaではヒープ領域上に確保したメモリ管理システムのこともヒープと呼びます。 以下の文章でヒープと表現する場合はすべてヒープ領域を指すものとします。 スタック領域とヒープ領域の違い ヒープ領域とスタック領域は、どちらも一時的に確保されるメモリ領域です。両者は
ファームウェアエンジニアの中林 (id:tomo-wait-for-it-yuki) です。ESP32愛好家の皆様、ESP-IDF v4.3で次の変更が入ったことにお気づきでしょうか？ Heap: Switched heap algorithm to one based on TLSF, improves performance especially when using a high number of allocations in PSRAM リリースノート1にさらっと1行だけ書かれていますが、「え？ヒープアロケータ変わったの？インパクト大きくない？」というのが最初の印象でした。本エントリではこのさらっと入った変更の、意外と大きな影響について解説して参りたいと思います。 本エントリの要点は次の通りです。 ESP-IDF v4.3からヒープアロケータがフリーリストアロケータからTLSFア
2011.6 やあみんな、ビリーだよ。 今回は、メモリの使いかたについて説明してみよう。 これまでにビリーが講義した、 「七の巻：スタックってなあに？」 「八の巻：メモリを壊してみましょう」 「拾壱の巻：コードサイズを聞かれたら」 で復習しておくと、さらに理解度アップだよ！ セクションとヒープ領域とスタック領域 プログラムの本、コンパイラのマニュアルなどを見ていると、ヒープ領域やスタック領域という言葉が出て来るよね。これはいったい何だろう？メモリの領域をさしているようだけど、「拾壱の巻：コードサイズを聞かれたら」で解説した、セクションとは違うのかな？『セクション』は、ROMやRAMをどのような用途に使うかを決めるものなんだ。「プログラム(コード)を配置する領域」「データを配置する領域」などだね。 組込みの世界では、一般的にプログラムやOSをコンパイル(リンク)した時点でセクションのアドレス
環境 インスタンス：t3a.nano OS: AmazonLinux2 node.js:v14.3.0 上記環境でnpm run serveを実施してVueアプリの動作確認をした後に npm run buildでビルドを実行したところ FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
こんにちは、 @kz_morita です。 みかん本 で自作OSの開発を進めていくなかで学びになったメモリ周りの知識についてまとめます． プロセスのセグメント配置について 実行されたプログラムは，メモリ上にロードされ実行されますがざっくりと以下の様な構造になっています． .text : プログラムのうち機械語を格納するセグメント .data : プログラム上の初期化されたデータを格納するセグメント .bss : 初期化されていないデータを格納するセグメント．OS (exec) が自動で0に初期化する スタックは，関数呼び出しなどで使用され，保存される情報とともに局所変数(auto 変数) や関数の引数が置かれます．大きいアドレスから小さいアドレスの方向に向かって伸びていきます． ヒープは，動的にメモリを割り当てる場所で，主に malloc などによりメモリ確保されるとヒープに配置されます．
ヒープとは ヒープとはデータ構造の一種であり、親要素が子要素よりも常に大きい（あるいは小さい）という特徴を持つ木構造です。つまり、ヒープの根が最大値（あるいは最小値）になり、$O(1)$ で参照することができます。またデータの挿入や最大値（あるいは最小値）の削除も $O(\log{N})$ と高速で可能なことから、優先度付きキューの実装としても利用されています。本記事では、特に二分木を使用した二分ヒープについて扱います。 ヒープ化にかかる計算量 ヒープ化されてない配列からヒープを作成する場合の計算量についてですが、1つのデータの挿入に $O(\log{N})$ 要することから考えると、直感的には $O(N\log{N})$ になりそうですが、実際には $O(N)$ で可能です。一例として、Python の heapq の実装にも線形時間でリストをヒープに変換するとの記述があります。 hea
こんにちは。カート決済部カート決済基盤ブロックの長沼です。先日Javaアプリケーションをリリースしたのですが、リリース後にOld領域のメモリ使用量がわずかに増加し続ける現象が発生しました。本記事ではこの現象の調査にて得られた知見を共有します。 本記事で共有すること 前提知識 JVM（Java Virtual Machine）とは ヒープ領域とは GC（ガベージ・コレクション）とは GCのアルゴリズム G1GC（ガベージファースト・ガベージ・コレクタ）とは G1GCのメモリ管理 ヒープ領域の概念図 世代別領域に対するGCの基本処理 Young GC 混合GC Full GC ソフト参照 Javaの参照 ソフト参照とGC まとめ 最後に 本記事で共有すること GCの概要を理解するための前提知識を説明した後、G1GC（ガベージファースト・ガベージ・コレクタ）がメモリをどのように扱うか説明します。
「休憩中Gopherくん」 Powered by Gopherize.me - A Gopher pic that's as unique as youThe Gopher character is based on the Go mascot designed by Renée French はじめに このブログを書こうとしたきっかけ 目的 用語の意味 メモリ レキシカルスコープ GC アロケーション コンパイラ ランタイム 「Where Go Values Live」について スタック ヒープ スタックとヒープにそれぞれ割り当てられる場合 終わりに 参考にさせていただいた記事 はじめに こんにちは！！！！ライクル事業部エンジニアの黒田(@knkurokuro7)です。 画像のGopherくんみたいに休憩中はよくコーヒーを飲んでいます！笑 今日もGoについてブログを書こうと思います！ こ
struct SelfRef { x: u32, // ptrは常にxを指していて欲しいが、SelfRefがムーブした瞬間に別のアドレスを指すようになる ptr: *const u32, } impl SelfRef { pub fn new(x: u32) -> SelfRef { let mut this = SelfRef { x, ptr: std::ptr::null(), }; this.ptr = &this.x; // まだアドレスは変わらないのでテストは成功する assert_eq!(&this.x as *const _, this.ptr); // ここで値を返した瞬間にxのアドレスが変わり、ptrの値が不正となる this } } fn main() { let v = SelfRef::new(0); // v.xとv.ptrの値が異なるためテスト失敗 asser
TL; DR ヒープとスタックは違う メモリは0と1 gdb楽しい はじめに 以前に引き続き、C compilerを作っている ポインタが思いの他簡単に実装できて感動していたら、ポインタと数字の加減算でめちゃくちゃにハマった あっちこっちデバッグして、原因を探っていったら飛ぶように1週間ほど経っていたが、さきほど原因が判明してめっちゃ感動して、この記事を書き出した 書き上げるのに2日ぐらいかかってしまった 原因を探っていく過程で、スタックマシンとメモリについての理解が深まった その記録 簡単なポインタの加減算 実装しようとしたのは、compiler bookのここ 「まだ配列がないので、mallocする」と書いてあったのでmalloc関数を使うのかと思いきや、mallocを使って配列をアロケートする方法がよく分からず肝心のテストが書けない 秘伝のあんちょこ、本家9ccのcommit log
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
