Segmentation fault while calling singlejar_local with pureconfig-core_2.12-0.14.1.jar

[eed3si9n]

Description of the problem / feature request:

When building a deploy JAR (über JAR) with pureconfig-core_2.12-0.14.1.jar, singlejar_local fails with a "Segmentation fault".

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

bazel build //:java-maven_deploy.jar

WORKSPACE

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

RULES_JVM_EXTERNAL_TAG = "2.5"

RULES_JVM_EXTERNAL_SHA = "249e8129914be6d987ca57754516be35a14ea866c616041ff0cd32ea94d2f3a1"

http_archive(
    name = "rules_jvm_external",
    sha256 = RULES_JVM_EXTERNAL_SHA,
    strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
    url = "https://github.com/bazelbuild/rules_jvm_external/archive/%s.zip" % RULES_JVM_EXTERNAL_TAG,
)

load("@rules_jvm_external//:defs.bzl", "maven_install")

maven_install(
    artifacts = [
        "com.github.pureconfig:pureconfig-core_2.12:0.14.1"
    ],
    repositories = [
        "https://repo1.maven.org/maven2",
    ],
)

BUILD

load("@rules_java//java:defs.bzl", "java_binary", "java_library", "java_test")

package(default_visibility = ["//visibility:public"])

java_library(
    name = "java-maven-lib",
    srcs = ["App.java"],
    deps = ["@maven//:com_github_pureconfig_pureconfig_core_2_12"],
)

java_binary(
    name = "java-maven",
    main_class = "com.example.myproject.App",
    runtime_deps = [":java-maven-lib"],
)

App.java

package com.example.myproject;

public class App {
  public static void main(String... args) throws Exception {
    App app = new App();
    System.out.println("hello");
  }
}

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

release 4.2.1

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

$ git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
https://github.com/bazelbuild/examples
b29794fb55f6714442dd86946c77f8908321a430
b29794fb55f6714442dd86946c77f8908321a430

Any other information, logs, or outputs that you want to share?

Please see pureconfig/pureconfig#1142.

It seems like either the JAR contains a faulty extra field size, or singlejar is parsing it wrong? Either case, from the point of view of OutputJar::AppendToDirectoryBuffer currently it appears to parse as follows:

  - pureconfig/Derivation$.classUT
    - ef_size 11 <- this is likely a bad value
    - ef->tag 0x5455, ef->payload_size 5, ef->size 9
    - ef->tag 0xbdbf, ef->payload_size 49135, ef->size 49139

Likely ef_size should have been 9, but it reports 11, and that overruns the ef->palyload_size() into next segment and end up with nonsensical 49135. I think it would be more robust to ignore faulty fields by trying not to go over the ef_size boundary while calculating the payload_size instead of seg faulting.

bazel/src/tools/singlejar/output_jar.cc

Lines 758 to 767 in 3ada002

	ExtraField *out_ef = out_ef_begin;
	for (const ExtraField *ef = ef_begin; ef < ef_end; ef = ef->next()) {
	if ((fix_timestamp && ef->is_unix_time()) || ef->is_zip64()) {
	// Skip this one.
	} else {
	memcpy(out_ef, ef, ef->size());
	out_ef = reinterpret_cast<ExtraField *>(
	reinterpret_cast<uint8_t *>(out_ef) + ef->size());
	}
	}

[eed3si9n]

FWIW, zipinfo, available as unzip -Z reports "length of extra field" to be 17 bytes, not 11. Given that Extended Timestamp Extra Field is a variable length field of 5 + 4 * x, 17 makes sense (likely corresponding to last modification, last access, and creation timestamps).

$ unzip -Z -v ~/Downloads/pureconfig-core_2.12-0.14.1.jar | less

  pureconfig/Derivation$.class

  offset of local header from start of archive:   140006
                                                  (00000000000222E6h) bytes
  file system or operating system of origin:      MS-DOS, OS/2 or NT FAT
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          yes
  file last modified on (DOS date/time):          2021 Feb 28 20:18:48
  32-bit CRC value (hex):                         c6d92ca2
  compressed size:                                316 bytes
  uncompressed size:                              469 bytes
  length of filename:                             28 characters
  length of extra field:                          17 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             000000 hex
  MS-DOS file attributes (00 hex):                none

It also shows

$ unzip -Z -v ~/Downloads/pureconfig-core_2.12-0.14.1.jar | rg "error"


  error: EF data block (type 0xbdbf) size 49135 exceeds remaining extra field
         space 4; block length has been truncated.

so this doesn't rule out JAR file containing bad data.

[philwo]

FYI @cushon

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[eed3si9n]

Is @bazelbuild/triage reachable publicly? https://github.com/orgs/bazelbuild/teams is not open.

This is a report of segfault during bazel build reproducible using a publicly available JAR. It should be fixed or kept open?

[fmeum]

@bazelbuild/triage just in case

[jluehe]

I'm facing same issue with the Jetty 10.0.16 distribution jar files:

ERROR: /Users/jluehe/.cache/bazel/b43a7dfcec516c88c9e468e65536bc1f/external/org_eclipse_jetty_jetty_util/BUILD:9:12: Extracting interface @org_eclipse_jetty_jetty_util//:org_eclipse_jetty_jetty_util failed: (Segmentation fault): ijar failed: error executing command (from target @org_eclipse_jetty_jetty_util//:org_eclipse_jetty_jetty_util) external/remote_java_tools_darwin/java_tools/ijar/ijar external/org_eclipse_jetty_jetty_util/jetty-util-10.0.16.jar ... (remaining 3 arguments skipped)

There are no issues with Jetty 10.0.15 ...