This bug seems to be fixed as of this commit. Update Intellij to get the new version.

If you can't update, a workaround to this is removing gradle aware make from the run process, and only build your code when you make a change (and not every time you start the debug)

Explanation to fix:

Hitting breakpoints in Kotlin JUnit test with an Android Gradle
project sometimes(*) does not work in Android Studio 3.1 beta.

(*) The issue is related to various threads running concurrently
with "dumb" mode background code, so the issue reproduces only
on certain configurations.

In a nutshell, the issue is as follows

* On one hand, gradle build finishes, fires an event ("buildFinished")
  that is processed "later" and that causes the IDE to enter "dumb" mode
  for a shot amount of time (about 300-500 msec on a somewhat up to date
  multi-core computer).

* On the other hand, once the JVM of the debuggee is started, breakpoints
  need to be resolved (on the debugger thread, through a call to
  com.intellij.debugger.engine.CompoundPositionManager.createPrepareRequests.
  This code calls into the "KotlinPositionManager.createPrepareRequests",
  which in turns calls into "PerFileAnalysisCache.analyze". That method
  returns "AnalysisResult.EMPTY" is the project is in dumb mode.
  This return value prevents callers from successfully resolving
  the source location into a breakpoint.

Given that the 2 code paths above execute on separate threads without
explicit synchronization, the "failed to resolve breakpoint" issue
occurs sporadically, to the point it happens 100% of the time on
certain configuration.

The fix is so wrap the kotlin breakpoint resolution code inside
a "runReadActionInSmartMode" so that the debugger thread "waits"
for "dumb" mode to terminates before trying to resolve breakpoint
locations.

It's currently not possible to set breakpoints in Kotlin for functions marked with a InlineOnly annotation, and require is one of such functions. Inline functions marked with this annotation don't provide additional debug information in order to save a line from the call site untouched in stack-traces, but it also ruins setting breakpoints inside (https://youtrack.jetbrains.com/issue/KT-24306).

You have spotted one workaround - using exception breakpoints (https://www.jetbrains.com/help/idea/creating-exception-breakpoints.html). IllegalArgumentException would be the best class in this case.

If there're calls in your code that don't work, they might be replaced to custom function as another workaround.

(The answer was updated. The previous version erroneously claimed that breakpoints in require might work for some calls.)

Did some searching through IntelliJ Help PDF:
Help Doc pg. 431

Their documentation Describes the checkmark as "Shown at run-time when the breakpoint is recognized by the debugger as set on an executable code line."

and the regular red dot as "Shown at design-time or during the debugging session when the class with such breakpoint is not yet loaded. "

So it would seem that the line you're adding the breaking point to never gets executed. You can try stepping up line by line through the class to make sure the class is not getting hung up somewhere.

Your function xxx uses Object Expression to create an object of anonymous class inheriting from dummyInterface. Problem is that you are not using this object anywhere, neither are you storing its reference so it's just created and never called.

For debug to stop at your breakpoint you have to actually call the method.

val obj = object : dummyInterface {
    override fun bbb() {
        println("yoyo")
    }
}
obj.bbb()

I figured out what my issue was and I think the problem is specific to me and the nature of my application. Actually I should call it a self induced issue. Let me explain the nature of events.

1. I have been using eclipse to develop and have a local install of weblogic instance. My application needs coherence cache server and I have few other JVM parameters that I pass when starting the domain. Therefore I had added a line at the start of the $DOMAIN_HOME/bin/setDomainEnv.sh file like so

   JAVA_OPTIONS="- Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.wka=devmachine and blah blah blah

2. I switched to intellij and started working on this project and then configured the weblogic plugin and run configuration etc.

3. I noticed that intellij adds a JAVA_OPTIONS in the startup/connection tab in Run/Debug Configurations like so

4. However the JAVA_OPTIONS that was being passed by intellij was not being used by weblogic. I believe it was overridden with what was in the setDomainEnv.sh which is why I saw the following logs.

java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode) Starting WLS with line: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -client -Xms512m -Xmx512m -XX:MaxPermSize=256m -Dweblogic.Name=AdminServer -Djava.security.policy=/Users/dparupud/omw/oracle/middleware/weblogic_10.3.6/wlserver_10.3/server/lib/weblogic.policy -Dtangosol.coherence.distributed.localstorage=false -Dtangosol.coherence.wka=devmachine blah blah blah......

5. When I went and removed the JAVA_OPTIONS from setDomainEnv.sh and restarted the server from intellij I saw the following log

starting weblogic with Java version: java version "1.6.0_65" Java(TM) SE Runtime Environment (build 1.6.0_65-b14-466.1-11M4716) Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-466.1, mixed mode) Starting WLS with line: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java -client -Xms512m -Xmx512m -XX:MaxPermSize=256m -Dweblogic.Name=AdminServer -Djava.security.policy=/Users/dparupud/omw/oracle/middleware/weblogic_10.3.6/wlserver_10.3/server/lib/weblogic.policy - agentlib:jdwp=transport=dt_socket,address=127.0.0.1:65501,suspend=y,server=n

Now the log showed that the jdwp agent was in action. I did notice that I did not see that particular log before I asked the Question on SO but I thought maybe IntelliJ was doing something inside the covers because JAVA_OPTIONS was being passed and intellij does not allow you to mess with that ( it is readonly).

I guess I can either pass all my jvm parameters either from intellij or add the jdwp agent info in the setDomainEnv.sh.

Now I am able to debug.