Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]

I know this question has been asked before, but I have read all the threads and I didn't find an answer. From the moment I execure run to start debugging my project, I get this : Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]. When I do ctrl+c, gdb tells me : Program received signal SIGINT, Interrupt. 0x00000000 in ?? ()

Usually it'll tell me which file and which function it got interrupted at not 0x00000000 in ?? () GDB no longer hits breakpoints, and what makes matter crazier is the fact that a colleague and I, are sharing the same session (the debug is done using cygwin with a remote machine) and it works fine for them but not for me. when I try to get info about the threads using info threads here's what I get :

[New Thread 20]
 [New Thread 21]
 [New Thread 22]
  Id   Target Id         Frame
  4    Thread 22 (ssp=0xa9004d5c) 0x00000000 in ?? ()
  3    Thread 21 (ssp=0xa9002e64) 0x00000010 in ?? ()
  2    Thread 20 (ssp=0xa9000ef4) 0x00000000 in ?? ()

The current thread <Thread ID 1> has terminated.  See `help thread'

there's no thread 6, there's no * to indicate which thread gdb is using. And I don't even know if that's linked to the problem. Can anyone please help me?

You are not providing nearly enough info to help you. Details matter, and you are withholding them. Versions of GDB and gdbserver matter, how you invoke GDB and gdbserver matter, what warnings you receive from GDB (if any) matter.

Now, this error message:

Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 6]

usually means that gdbserver has not attached one of the threads of your process, and that thread has tried to execute breakpoint instruction (you do have breakpoints set before this happens, don't you?).

One of the reasons this may happen is when your GDB loads "wrong" libthread_db.so (one that doesn't match the target libc.so.6).

what makes matter crazier is the fact that a colleague and I, are sharing the same session (the debug is done using cygwin with a remote machine) and it works fine for them but not for me.

I am not sure what you mean by "same session", but it's probably not "when he types commands, they work; but when I type the same commands into the same GDB, they don't".

One difference between you and your colleague could be LD_LIBRATY_PATH environment variable setting. Another could be in ~/.gdbinit or in ./.gdbinit.

I suggest running gdb -nx to get rid of the latter, and unsetting LD_LIBRARY_PATH to get rid of the former.