跳至主要内容

Interesting bug of intellij decompiler

Strange char

When I view the source of a project, I notice it use log4j. So, I click into the logger.error method, and intellij decompile the class file and show the following code:
public void error(Object message, Throwable t) {
    if(!this.repository.isDisabled('鱀')) {//<--here
        if(Level.ERROR.isGreaterOrEqual(this.getEffectiveLevel())) {
            this.forcedLog(FQCN, Level.ERROR, message, t);
        }
    }
}
I was attracted by that strange character, because this character is so rare, so who would use such char in the code? There must be some reason.

Real source

It is strange, right? I am curious about that strange character so I find the source as following:
void error(Object message, Throwable t) {
  if(repository.isDisabled(Level.ERROR_INT))
    return;
  if(Level.ERROR.isGreaterOrEqual(this.getEffectiveLevel()))
    forcedLog(FQCN, Level.ERROR, message, t);
}

// Level.ERROR_INT
public final static int ERROR_INT = 40000;
Now, we understand it. When intellij decompile the class, it convert the int 40000 to a char(which has a range of 0-65535).

Verify

But it may be the java compiler who see it is a int can represented by a char and change it. So I decompile the class file use javap to see whether it is represented by a char or int.
javap -c Category.class
  public void error(java.lang.Object, java.lang.Throwable);
    Code:
       0: aload_0
       1: getfield      #13                 // Field repository:Lorg/apache/log4j/spi/LoggerRepository;
       4: ldc           #31                 // int 40000
       6: invokeinterface #25,  2           // InterfaceMethod org/apache/log4j/spi/LoggerRepository.isDisabled:(I)Z
      11: ifeq          15

// ldc means: push a constant #index from a constant pool (String, int or float) onto the stack
From the line 4, we can see it indeed a int, so it is some kind of bug.

char to int

Actually, when I write a large unicode char in source code, java compiler will automatically change it to a int
  final char c2 = '鱀';
  System.out.println(c2);
  System.out.println('c');

  125: ldc           #19                 // int 40000 -- here
  127: istore        5
  129: getstatic     #5                  // Field java/lang/System.out:Ljava/io/PrintStream;
  132: ldc           #19                 // int 40000 -- and here
  134: invokevirtual #20                 // Method java/io/PrintStream.println:(C)V
  137: getstatic     #5                  // Field java/lang/System.out:Ljava/io/PrintStream;
  140: bipush        99
  142: invokevirtual #20                 // Method java/io/PrintStream.println:(C)V
A simple code snippet can be get from here

Ref

Written with StackEdit.

评论

此博客中的热门博文

Spring Boot: Customize Environment

Spring Boot: Customize Environment Environment variable is a very commonly used feature in daily programming: used in init script used in startup configuration used by logging etc In Spring Boot, all environment variables are a part of properties in Spring context and managed by Environment abstraction. Because Spring Boot can handle the parse of configuration files, when we want to implement a project which uses yml file as a separate config file, we choose the Spring Boot. The following is the problems we met when we implementing the parse of yml file and it is recorded for future reader. Bind to Class Property values can be injected directly into your beans using the @Value annotation, accessed via Spring’s Environment abstraction or bound to structured objects via @ConfigurationProperties. As the document says, there exists three ways to access properties in *.properties or *.yml : @Value : access single value Environment : can access multi...

LevelDB Source Reading (4): Concurrent Access

In this thread, we come to the issue of concurrent access of LevelDB. As a database, it can be concurrently accessed by users. But, it wouldn’t be easy to provide high throughput under product load. What effort does LevelDB make to achieve this goal both in design and implementation? Goal of Design From this github issue , we can see LevelDB is designed for not allowing multi-process access. this (supporting multiple processes) doesn’t seem like a good feature for LevelDB to implement. They believe let multiple process running would be impossible to share memory/buffer/cache, which may affect the performance of LevelDB. In the case of multiple read-only readers without altering the code base, you could simply copy the file for each reader. Yes, it will be inefficient (though not on file systems that dedupe data), but then again, so would having multiple leveldb processes running as they wouldn’t be able to share their memory/buffer/etc. They achieve it by adding a l...

LevelDB Source Reading (3): Compaction

LevelDB Source Reading (3): Compaction In the last blog that analyzes read/write process of Leveldb, we can see writing only happens to log file and memory table, then it relies on the compaction process to move the new updates into persistent sorted table for future use. So the compaction is a crucial part for the design, and we will dive into it in this blog. Compaction LevelDB compacts its underlying storage data in the background to improve read performance. The upper sentence is cited from the document of Leveldb , and we will see how it is implemented via code review. Background compaction // db_impl.cc void DBImpl :: MaybeScheduleCompaction ( ) { // use background thread to run compaction env_ - > Schedule ( & DBImpl :: BGWork , this ) ; } Two main aspects // arrange background compaction when Get, Open, Write void DBImpl :: BackgroundCompaction ( ) { // compact memtable CompactMemTable ( ) ; // compact ...