View Issue Details

IDProjectCategoryView StatusLast Update
0000968Ecere SDKidepublic2013-09-28 23:58
Reporterredj Assigned Toredj  
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version0.44.08 
Target Version0.44.10 64Fixed in Version0.44.10 64 
Summary0000968: toggle breakpoint in file with same name with two projects in workspace will set bp in wrong project/file half the time
Descriptionas summarized
TagsNo tags attached.

Relationships

related to 0000103 closedjerome Trying to set a breakpoint in a library (List.ec) while file with same name exists in Main Project does not work 

Activities

redj

2013-07-16 19:44

administrator   ~0000930

from notes in [0000666]
----------------------------------------------
However, I noticed that having 2 different instances of harfbuzz-shaper.c (Could probably be any file named the same) in 2 added projects (both shared libraries), setting a breakpoint in one of them will still go to the wrong project.
----------------------------------------------
looked into this same file business a bit... not sure how we will fix this!
it depends a lot on gdb...

jerome

2013-08-24 07:18

administrator   ~0000999

Last edited: 2013-08-24 07:24

Please document how this was fixed and link to a commit, as well as your test case in 'Steps to reproduce' so I can verify this was fixed.

redj

2013-08-24 11:34

administrator   ~0001001

Last edited: 2013-08-24 16:56

fixed by https://github.com/ecere/ecere-sdk/commit/715705e741123c0e2f20f937ae64016506b79802

SetBreakpoint handles multiple address breakpoints
   if(bpItem.multipleBPs && bpItem.multipleBPs.count)
and it will disable all breakpoints set in the wrong file
   if(!fstrcmp(n.fullname, bp.absoluteFilePath))
   ...
   else
   GdbCommand(false, "-break-disable %s", n.number);


See attached file for test case.

2013-08-24 11:39

 

sameFileName.zip (23,783 bytes)

jerome

2013-08-28 17:32

administrator   ~0001020

Last edited: 2013-08-28 18:06

I tested in my own test case, and this is still a problem.

I have the same file in different paths for each shared library additional projects, and toggling the breakpoint puts it with the wrong path.

redj

2013-08-29 00:08

administrator   ~0001028

https://github.com/redj/ecere-sdk/commit/a5f5f25ab798abb9df852a7d40aa86723618f180

jerome

2013-08-29 08:59

administrator   ~0001033

Last edited: 2013-08-29 08:59

It's nice to see the right breakpoint in the BreakpointView when toggling it in the code editor. I will push 77c4082ec497ef535b2c74d8b1b4b6730489866f to master regardless, as it seems to be a step in the right direction and not break anything that was previously working.

However the breakpoint functionality still needs some work, if GDB can allow.

- After setting both breakpoints, and reloading the project, the 2 different paths are kept, but they both show up as if they were in the same project (always the same project, regardless of the order)

- There seems to be a problem related to setting up the breakpoint before the other dynamic library is loaded.

- If after the first breakpoint in ecere is hit, I toggle off/on the other library breakpoint, all hits will happen a the right place (7 in Ecere, 1 in the other) with the proper call stacks and everything. Otherwise the other library will never hit.

- If I set a breakpoint in the other lib, it will pretend to be hitting in ecere, with the ecere location and call stack, but the breakpoint icon and breakpoints view thinks it set a breakpoint in the other lib

- Many GDB warnings show up in the Debug log:

GDB: No source file named src/gfx/drivers/harfbuzz/harfbuzz-shaper.c.
GDB: No source file named harfbuzz-shaper.c.
GDB: No source file named src/Platforms/TextEngine/harfbuzz/harfbuzz-shaper.c.
GDB: No source file named harfbuzz-shaper.c.
GDB: No source file named src/Platforms/TextEngine/harfbuzz/harfbuzz-shaper.c.

 Temporarily disabling breakpoints for unloaded shared library ...

jerome

2013-09-10 18:40

administrator   ~0001058

Fixed by https://github.com/ecere/ecere-sdk/commit/0de8ceef742f54e87f1c2f43158548efbef0ce72

Issue History

Date Modified Username Field Change
2013-07-16 19:43 redj New Issue
2013-07-16 19:44 redj Note Added: 0000930
2013-08-07 01:04 jerome Target Version 0.44.10 64 => 0.44.08
2013-08-07 01:04 jerome Status new => assigned
2013-08-07 01:04 jerome Assigned To => redj
2013-08-09 10:54 jerome Target Version 0.44.08 => 0.44.10 64
2013-08-16 18:48 jerome Target Version 0.44.10 64 => 0.44.09
2013-08-22 20:17 redj Status assigned => resolved
2013-08-22 20:17 redj Resolution open => fixed
2013-08-24 07:18 jerome Note Added: 0000999
2013-08-24 07:18 jerome Status resolved => assigned
2013-08-24 07:19 jerome Note Edited: 0000999
2013-08-24 07:24 jerome Note Edited: 0000999
2013-08-24 11:34 redj Note Added: 0001001
2013-08-24 11:39 redj File Added: sameFileName.zip
2013-08-24 11:43 redj Note Edited: 0001001
2013-08-24 11:50 redj Status assigned => resolved
2013-08-24 11:51 redj Fixed in Version => 0.44.09
2013-08-24 16:56 jerome Note Edited: 0001001
2013-08-28 17:32 jerome Note Added: 0001020
2013-08-28 17:32 jerome Status resolved => assigned
2013-08-28 18:06 jerome Note Edited: 0001020
2013-08-29 00:08 redj Status assigned => resolved
2013-08-29 00:08 redj Note Added: 0001028
2013-08-29 08:59 jerome Note Added: 0001033
2013-08-29 08:59 jerome Status resolved => assigned
2013-08-29 08:59 jerome Note Edited: 0001033
2013-08-30 03:05 jerome Resolution fixed => reopened
2013-08-30 03:05 jerome Product Version 0.44.07 => 0.44.08
2013-08-30 03:05 jerome Fixed in Version 0.44.09 64 =>
2013-08-30 03:05 jerome Target Version 0.44.09 64 => 0.44.10 Tablet Edition
2013-09-08 18:25 jerome Target Version 0.44.11 Tablet Edition/Docs => 0.44.10 64
2013-09-10 18:40 jerome Status assigned => resolved
2013-09-10 18:40 jerome Fixed in Version => 0.44.10 64
2013-09-10 18:40 jerome Resolution reopened => fixed
2013-09-10 18:40 jerome Note Added: 0001058
2013-09-28 23:58 jerome Status resolved => closed
2014-05-01 10:45 jerome Relationship added related to 0000103