[Bug gdb/31254] New: [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[Bug gdb/31254] New: [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

            Bug ID: 31254
           Summary: [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10
           Product: gdb
           Version: 13.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

A failure I see being reported with the linaro CI for arm is:
...
(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
up 10
#4  0x0001b864 in pthread_join ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|13.1                        |HEAD

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15308
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15308&action=edit
gdb.log.gz

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
AFAIU, the failure is to unwind past pthread_join.

It would be nice to see what bt produces just before the "up 10".

I added this on my pinebook (where the test-case passes), and got:
...
(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
bt^M
#0  0x000162f4 in __libc_do_syscall ()^M
#1  0x000124a4 in __pthread_clockjoin_ex (threadid=4152297568,
thread_return=0x0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
block=block@entry=true) at pthread_join_common.c:145^M
#2  0x000122d4 in __pthread_join (threadid=<optimized out>,
thread_return=<optimized out>) at pthread_join.c:24^M
#3  0x00010568 in main (argc=1, argv=0xfffeee24) at
/home/rock/gdb/src/gdb/testsuite/gdb.threads/staticthreads.c:76^M
(gdb) PASS: gdb.threads/staticthreads.exp: bt
up 10^M
#3  0x00010568 in main (argc=1, argv=0xfffeee24) at
/home/rock/gdb/src/gdb/testsuite/gdb.threads/staticthreads.c:76^M
76          pthread_join (thread, NULL);^M
(gdb) PASS: gdb.threads/staticthreads.exp: up 10
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis.machado at arm dot com,
                   |                            |thiago.bauermann at linaro dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> Created attachment 15308 [details]
> gdb.log.gz

One thing I noticed is this:
...
(gdb) run
`/home/tcwg-build/workspace/tcwg_gnu_0/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gdb-gdb.git~master/gdb/testsuite/outputs/gdb.threads/staticthreads/staticthreads'
has changed; re-reading symbols.
...

I'm not sure how that happens.  May be unrelated to the FAIL though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #4 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
The problem is that the backtrace goes through internal details of glibc, so
the "up 10" command makes assumptions about the internal organization of glibc,
which is fragile.

Most of the time this checks out, but occasionally <hand wave>the inferior is
in such a state</hand wave> that the number of frames to reach main doesn't
match.

I am in the middle of fixing the testcase to go up the stack one frame at a
time and checking when it gets to main. Do you agree it's a proper fix?

I'll probably be able to post it by EOD today or tomorrow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #5 from Luis Machado <luis.machado at arm dot com> ---
Is this one of those cases where having too much symbol/debug info information
is actually causing tests to FAIL (due to tests being fragile)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #6 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Ha, there may be something else going on. I just added a `gdb_test "bt"`right
before the `up 10` command and let the test running in a loop until it failed,
and just got this:

(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
bt
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x000405ba in __futex_abstimed_wait_common ()
#2  0x000405ba in __futex_abstimed_wait_common ()
#3  0x000405ba in __futex_abstimed_wait_common ()
#4  0x000405ba in __futex_abstimed_wait_common ()
#5  0x000405ba in __futex_abstimed_wait_common ()
#6  0x000405ba in __futex_abstimed_wait_common ()
#7  0x000405ba in __futex_abstimed_wait_common ()
#8  0x000405ba in __futex_abstimed_wait_common ()
#9  0x000405ba in __futex_abstimed_wait_common ()
#10 0x000405ba in __futex_abstimed_wait_common ()
#11 0x000405ba in __futex_abstimed_wait_common ()
#12 0x000405ba in __futex_abstimed_wait_common ()
#13 0x000405ba in __futex_abstimed_wait_common ()
#14 0x000405ba in __futex_abstimed_wait_common ()
#15 0x000405ba in __futex_abstimed_wait_common ()
#16 0x000405ba in __futex_abstimed_wait_common ()
#17 0x000405ba in __futex_abstimed_wait_common ()
#18 0x000405ba in __futex_abstimed_wait_common ()
#19 0x000405ba in __futex_abstimed_wait_common ()
#20 0x000405ba in __futex_abstimed_wait_common ()
#21 0x000405ba in __futex_abstimed_wait_common ()
#22 0x000405ba in __futex_abstimed_wait_common ()
#23 0x000405ba in __futex_abstimed_wait_common ()
#24 0x000405ba in __futex_abstimed_wait_common ()
#25 0x000405ba in __futex_abstimed_wait_common ()
#26 0x000405ba in __futex_abstimed_wait_common ()
#27 0x000405ba in __futex_abstimed_wait_common ()
#28 0x000405ba in __futex_abstimed_wait_common ()
#29 0x000405ba in __futex_abstimed_wait_common ()
#30 0x000405ba in __futex_abstimed_wait_common ()
#31 0x000405ba in __futex_abstimed_wait_common ()
#32 0x000405ba in __futex_abstimed_wait_common ()
#33 0x000405ba in __futex_abstimed_wait_common ()
#34 0x000405ba in __futex_abstimed_wait_common ()
#35 0x000405ba in __futex_abstimed_wait_common ()
#36 0x000405ba in __futex_abstimed_wait_common ()
#37 0x000405ba in __futex_abstimed_wait_common ()
#38 0x000405ba in __futex_abstimed_wait_common ()
#39 0x000405ba in __futex_abstimed_wait_common ()
#40 0x000405ba in __futex_abstimed_wait_common ()
#41 0x000405ba in __futex_abstimed_wait_common ()
#42 0x000405ba in __futex_abstimed_wait_common ()
#43 0x000405ba in __futex_abstimed_wait_common ()
#44 0x000405ba in __futex_abstimed_wait_common ()
#45 0x000405ba in __futex_abstimed_wait_common ()
#46 0x000405ba in __futex_abstimed_wait_common ()
#47 0x000405ba in __futex_abstimed_wait_common ()
#48 0x000405ba in __futex_abstimed_wait_common ()
#49 0x000405ba in __futex_abstimed_wait_common ()
#50 0x000405ba in __futex_abstimed_wait_common ()
#51 0x000405ba in __futex_abstimed_wait_common ()
#52 0x000405ba in __futex_abstimed_wait_common ()
#53 0x000405ba in __futex_abstimed_wait_common ()
#54 0x000405ba in __futex_abstimed_wait_common ()
#55 0x000405ba in __futex_abstimed_wait_common ()
#56 0x000405ba in __futex_abstimed_wait_common ()
#57 0x000405ba in __futex_abstimed_wait_common ()
#58 0x000405ba in __futex_abstimed_wait_common ()
#59 0x000405ba in __futex_abstimed_wait_common ()
#60 0x000405ba in __futex_abstimed_wait_common ()
#61 0x000405ba in __futex_abstimed_wait_common ()
#62 0x000405ba in __futex_abstimed_wait_common ()
#63 0x000405ba in __futex_abstimed_wait_common ()
#64 0x000405ba in __futex_abstimed_wait_common ()
#65 0x000405ba in __futex_abstimed_wait_common ()
#66 0x000405ba in __futex_abstimed_wait_common ()
#67 0x000405ba in __futex_abstimed_wait_common ()
#68 0x000405ba in __futex_abstimed_wait_common ()
#69 0x000405ba in __futex_abstimed_wait_common ()
#70 0x000405ba in __futex_abstimed_wait_common ()
#71 0x000405ba in __futex_abstimed_wait_common ()
#72 0x000405ba in __futex_abstimed_wait_common ()
#73 0x000405ba in __futex_abstimed_wait_common ()
#74 0x000405ba in __futex_abstimed_wait_common ()
#75 0x000405ba in __futex_abstimed_wait_common ()
#76 0x000405ba in __futex_abstimed_wait_common ()
#77 0x000405ba in __futex_abstimed_wait_common ()
#78 0x000405ba in __futex_abstimed_wait_common ()
#79 0x000405ba in __futex_abstimed_wait_common ()
#80 0x000405ba in __futex_abstimed_wait_common ()
#81 0x000405ba in __futex_abstimed_wait_common ()
#82 0x000405ba in __futex_abstimed_wait_common ()
#83 0x000405ba in __futex_abstimed_wait_common ()
#84 0x000405ba in __futex_abstimed_wait_common ()
#85 0x000405ba in __futex_abstimed_wait_common ()
#86 0x000405ba in __futex_abstimed_wait_common ()
#87 0x000405ba in __futex_abstimed_wait_common ()
#88 0x000405ba in __futex_abstimed_wait_common ()
#89 0x000405ba in __futex_abstimed_wait_common ()
#90 0x000405ba in __futex_abstimed_wait_common ()
#91 0x000405ba in __futex_abstimed_wait_common ()
#92 0x000405ba in __futex_abstimed_wait_common ()
#93 0x000405ba in __futex_abstimed_wait_common ()
#94 0x000405ba in __futex_abstimed_wait_common ()
#95 0x000405ba in __futex_abstimed_wait_common ()
#96 0x000405ba in __futex_abstimed_wait_common ()
#97 0x000405ba in __futex_abstimed_wait_common ()
#98 0x000405ba in __futex_abstimed_wait_common ()
#99 0x000405ba in __futex_abstimed_wait_common ()
#100 0x000405ba in __futex_abstimed_wait_common ()
#101 0x000405ba in __futex_abstimed_wait_common ()
#102 0x000405ba in __futex_abstimed_wait_common ()
#103 0x000405ba in __futex_abstimed_wait_common ()
#104 0x000405ba in __futex_abstimed_wait_common ()
#105 0x000405ba in __futex_abstimed_wait_common ()
#106 0x000405ba in __futex_abstimed_wait_common ()
#107 0x000405ba in __futex_abstimed_wait_common ()
#108 0x000405ba in __futex_abstimed_wait_common ()
#109 0x000405ba in __futex_abstimed_wait_common ()
#110 0x000405ba in __futex_abstimed_wait_common ()
#111 0x000405ba in __futex_abstimed_wait_common ()
#112 0x000405ba in __futex_abstimed_wait_common ()
#113 0x000405ba in __futex_abstimed_wait_common ()
#114 0x000405ba in __futex_abstimed_wait_common ()
#115 0x000405ba in __futex_abstimed_wait_common ()
#116 0x000405ba in __futex_abstimed_wait_common ()
#117 0x000405ba in __futex_abstimed_wait_common ()
#118 0x000405ba in __futex_abstimed_wait_common ()
#119 0x000405ba in __futex_abstimed_wait_common ()
#120 0x000405ba in __futex_abstimed_wait_common ()
#121 0x000405ba in __futex_abstimed_wait_common ()
#122 0x000405ba in __futex_abstimed_wait_common ()
#123 0x000405ba in __futex_abstimed_wait_common ()
#124 0x000405ba in __futex_abstimed_wait_common ()
#125 0x000405ba in __futex_abstimed_wait_common ()
#126 0x000405ba in __futex_abstimed_wait_common ()
#127 0x000405ba in __futex_abstimed_wait_common ()
#128 0x000405ba in __futex_abstimed_wait_common ()
#129 0x000405ba in __futex_abstimed_wait_common ()
#130 0x000405ba in __futex_abstimed_wait_common ()
#131 0x000405ba in __futex_abstimed_wait_common ()
#132 0x000405ba in __futex_abstimed_wait_common ()
#133 0x000405ba in __futex_abstimed_wait_common ()
#134 0x000405ba in __futex_abstimed_wait_common ()
#135 0x000405ba in __futex_abstimed_wait_common ()
#136 0x000405ba in __futex_abstimed_wait_common ()
#137 0x000405ba in __futex_abstimed_wait_common ()
#138 0x000405ba in __futex_abstimed_wait_common ()
#139 0x000405ba in __futex_abstimed_wait_common ()
#140 0x000405ba in __futex_abstimed_wait_common ()
#141 0x000405ba in __futex_abstimed_wait_common ()
#142 0x000405ba in __futex_abstimed_wait_common ()
#143 0x000405ba in __futex_abstimed_wait_common ()
#144 0x000405ba in __futex_abstimed_wait_common ()
#145 0x000405ba in __futex_abstimed_wait_common ()
#146 0x000405ba in __futex_abstimed_wait_common ()
#147 0x000405ba in __futex_abstimed_wait_common ()
#148 0x000405ba in __futex_abstimed_wait_common ()
#149 0x000405ba in __futex_abstimed_wait_common ()
#150 0x000405ba in __futex_abstimed_wait_common ()
#151 0x000405ba in __futex_abstimed_wait_common ()
#152 0x000405ba in __futex_abstimed_wait_common ()
#153 0x000405ba in __futex_abstimed_wait_common ()
#154 0x000405ba in __futex_abstimed_wait_common ()
#155 0x000405ba in __futex_abstimed_wait_common ()
#156 0x000405ba in __futex_abstimed_wait_common ()
#157 0x000405ba in __futex_abstimed_wait_common ()
#158 0x000405ba in __futex_abstimed_wait_common ()
#159 0x000405ba in __futex_abstimed_wait_common ()
#160 0x000405ba in __futex_abstimed_wait_common ()
#161 0x000405ba in __futex_abstimed_wait_common ()
#162 0x000405ba in __futex_abstimed_wait_common ()
#163 0x000405ba in __futex_abstimed_wait_common ()
#164 0x000405ba in __futex_abstimed_wait_common ()
#165 0x000405ba in __futex_abstimed_wait_common ()
#166 0x000405ba in __futex_abstimed_wait_common ()
#167 0x000405ba in __futex_abstimed_wait_common ()
#168 0x000405ba in __futex_abstimed_wait_common ()
#169 0x000405ba in __futex_abstimed_wait_common ()
#170 0x000405ba in __futex_abstimed_wait_common ()
#171 0x000405ba in __futex_abstimed_wait_common ()
#172 0x000405ba in __futex_abstimed_wait_common ()
#173 0x000405ba in __futex_abstimed_wait_common ()
#174 0x000405ba in __futex_abstimed_wait_common ()
#175 0x000405ba in __futex_abstimed_wait_common ()
#176 0x000405ba in __futex_abstimed_wait_common ()
#177 0x000405ba in __futex_abstimed_wait_common ()
#178 0x000405ba in __futex_abstimed_wait_common ()
#179 0x000405ba in __futex_abstimed_wait_common ()
#180 0x000405ba in __futex_abstimed_wait_common ()
#181 0x000405ba in __futex_abstimed_wait_common ()
#182 0x000405ba in __futex_abstimed_wait_common ()
#183 0x000405ba in __futex_abstimed_wait_common ()
#184 0x000405ba in __futex_abstimed_wait_common ()
#185 0x000405ba in __futex_abstimed_wait_common ()
#186 0x000405ba in __futex_abstimed_wait_common ()
#187 0x000405ba in __futex_abstimed_wait_common ()
#188 0x000405ba in __futex_abstimed_wait_common ()
#189 0x000405ba in __futex_abstimed_wait_common ()
#190 0x000405ba in __futex_abstimed_wait_common ()
#191 0x000405ba in __futex_abstimed_wait_common ()
#192 0x000405ba in __futex_abstimed_wait_common ()
#193 0x000405ba in __futex_abstimed_wait_common ()
#194 0x000405ba in __futex_abstimed_wait_common ()
#195 0x000405ba in __futex_abstimed_wait_common ()
#196 0x000405ba in __futex_abstimed_wait_common ()
#197 0x000405ba in __futex_abstimed_wait_common ()
#198 0x000405ba in __futex_abstimed_wait_common ()
#199 0x000405ba in __futex_abstimed_wait_common ()
#200 0x000405ba in __futex_abstimed_wait_common ()
#201 0x000405ba in __futex_abstimed_wait_common ()
#202 0x000405ba in __futex_abstimed_wait_common ()
#203 0x000405ba in __futex_abstimed_wait_common ()
#204 0x000405ba in __futex_abstimed_wait_common ()
#205 0x000405ba in __futex_abstimed_wait_common ()
#206 0x000405ba in __futex_abstimed_wait_common ()
#207 0x000405ba in __futex_abstimed_wait_common ()
#208 0x000405ba in __futex_abstimed_wait_common ()
#209 0x000405ba in __futex_abstimed_wait_common ()
#210 0x000405ba in __futex_abstimed_wait_common ()
#211 0x000405ba in __futex_abstimed_wait_common ()
#212 0x000405ba in __futex_abstimed_wait_common ()
#213 0x000405ba in __futex_abstimed_wait_common ()
#214 0x000405ba in __futex_abstimed_wait_common ()
#215 0x000405ba in __futex_abstimed_wait_common ()
#216 0x000405ba in __futex_abstimed_wait_common ()
#217 0x000405ba in __futex_abstimed_wait_common ()
#218 0x000405ba in __futex_abstimed_wait_common ()
#219 0x000405ba in __futex_abstimed_wait_common ()
#220 0x000405ba in __futex_abstimed_wait_common ()
#221 0x000405ba in __futex_abstimed_wait_common ()
#222 0x000405ba in __futex_abstimed_wait_common ()
#223 0x000405ba in __futex_abstimed_wait_common ()
#224 0x000405ba in __futex_abstimed_wait_common ()
#225 0x000405ba in __futex_abstimed_wait_common ()
#226 0x000405ba in __futex_abstimed_wait_common ()
#227 0x000405ba in __futex_abstimed_wait_common ()
#228 0x000405ba in __futex_abstimed_wait_common ()
#229 0x000405ba in __futex_abstimed_wait_common ()
#230 0x000405ba in __futex_abstimed_wait_common ()
#231 0x000405ba in __futex_abstimed_wait_common ()
#232 0x000405ba in __futex_abstimed_wait_common ()
#233 0x000405ba in __futex_abstimed_wait_common ()
#234 0x000405ba in __futex_abstimed_wait_common ()
#235 0x000405ba in __futex_abstimed_wait_common ()
#236 0x000405ba in __futex_abstimed_wait_common ()
#237 0x000405ba in __futex_abstimed_wait_common ()
#238 0x000405ba in __futex_abstimed_wait_common ()
#239 0x000405ba in __futex_abstimed_wait_common ()
#240 0x000405ba in __futex_abstimed_wait_common ()
#241 0x000405ba in __futex_abstimed_wait_common ()
#242 0x000405ba in __futex_abstimed_wait_common ()
#243 0x000405ba in __futex_abstimed_wait_common ()
#244 0x000405ba in __futex_abstimed_wait_common ()
#245 0x000405ba in __futex_abstimed_wait_common ()
#246 0x000405ba in __futex_abstimed_wait_common ()
#247 0x000405ba in __futex_abstimed_wait_common ()
#248 0x000405ba in __futex_abstimed_wait_common ()
#249 0x000405ba in __futex_abstimed_wait_common ()
#250 0x000405ba in __futex_abstimed_wait_common ()
#251 0x000405ba in __futex_abstimed_wait_common ()
#252 0x000405ba in __futex_abstimed_wait_common ()
#253 0x000405ba in __futex_abstimed_wait_common ()
#254 0x000405ba in __futex_abstimed_wait_common ()
#255 0x000405ba in __futex_abstimed_wait_common ()
#256 0x000405ba in __futex_abstimed_wait_common ()
#257 0x000405ba in __futex_abstimed_wait_common ()
#258 0x000405ba in __futex_abstimed_wait_common ()
#259 0x000405ba in __futex_abstimed_wait_common ()
#260 0x000405ba in __futex_abstimed_wait_common ()
#261 0x000405ba in __futex_abstimed_wait_common ()
#262 0x000405ba in __futex_abstimed_wait_common ()
#263 0x000405ba in __futex_abstimed_wait_common ()
#264 0x000405ba in __futex_abstimed_wait_common ()
#265 0x000405ba in __futex_abstimed_wait_common ()
#266 0x000405ba in __futex_abstimed_wait_common ()
#267 0x000405ba in __futex_abstimed_wait_common ()
#268 0x000405ba in __futex_abstimed_wait_common ()
#269 0x000405ba in __futex_abstimed_wait_common ()
#270 0x000405ba in __futex_abstimed_wait_common ()
#271 0x000405ba in __futex_abstimed_wait_common ()
#272 0x000405ba in __futex_abstimed_wait_common ()
#273 0x000405ba in __futex_abstimed_wait_common ()
#274 0x000405ba in __futex_abstimed_wait_common ()
#275 0x000405ba in __futex_abstimed_wait_common ()
#276 0x000405ba in __futex_abstimed_wait_common ()
#277 0x000405ba in __futex_abstimed_wait_common ()
#278 0x000405ba in __futex_abstimed_wait_common ()
#279 0x000405ba in __futex_abstimed_wait_common ()
#280 0x000405ba in __futex_abstimed_wait_common ()
#281 0x000405ba in __futex_abstimed_wait_common ()
#282 0x000405ba in __futex_abstimed_wait_common ()
#283 0x000405ba in __futex_abstimed_wait_common ()
#284 0x000405ba in __futex_abstimed_wait_common ()
#285 0x000405ba in __futex_abstimed_wait_common ()
#286 0x000405ba in __futex_abstimed_wait_common ()
#287 0x000405ba in __futex_abstimed_wait_common ()
#288 0x000405ba in __futex_abstimed_wait_common ()
#289 0x000405ba in __futex_abstimed_wait_common ()
#290 0x000405ba in __futex_abstimed_wait_common ()
#291 0x000405ba in __futex_abstimed_wait_common ()
#292 0x000405ba in __futex_abstimed_wait_common ()
#293 0x000405ba in __futex_abstimed_wait_common ()
#294 0x000405ba in __futex_abstimed_wait_common ()
#295 0x000405ba in __futex_abstimed_wait_common ()
#296 0x000405ba in __futex_abstimed_wait_common ()
#297 0x000405ba in __futex_abstimed_wait_common ()
#298 0x000405ba in __futex_abstimed_wait_common ()
#299 0x000405ba in __futex_abstimed_wait_common ()
#300 0x000405ba in __futex_abstimed_wait_common ()
#301 0x000405ba in __futex_abstimed_wait_common ()
#302 0x000405ba in __futex_abstimed_wait_common ()
#303 0x000405ba in __futex_abstimed_wait_common ()
#304 0x000405ba in __futex_abstimed_wait_common ()
#305 0x000405ba in __futex_abstimed_wait_common ()
#306 0x000405ba in __futex_abstimed_wait_common ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) PASS: gdb.threads/staticthreads.exp: bt
up 10
#10 0x000405ba in __futex_abstimed_wait_common ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #7 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Thiago Jung Bauermann from comment #4)
> Most of the time this checks out, but occasionally <hand wave>the inferior
> is in such a state</hand wave> that the number of frames to reach main
> doesn't match.

I did investigate this failure a few weeks ago, and I said the above because it
was the conclusion I reached back then. I have a memory of seeing a backtrace
which was correct but took more frames to reach main. So perhaps there's more
than one failure mode? I'll see if I can find my notes/gdb.log files from that
investigation.

Anyway, I ran the test in a loop again, and I got this:

(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
bt
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x000405ba in __futex_abstimed_wait_common ()
#2  0x32336862 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.threads/staticthreads.exp: bt
up 10
#2  0x32336862 in ?? ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10

So GDB is indeed having trouble unwinding __futex_abstimed_wait_common ()

By the way, these results (and also the Linaro CI failure mentioned on the bug
description) are on Ubuntu 22.04 with armv8l-linux-gnueabihf.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #8 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
I am not sure this is an glibc issue, I built the gdb testcase
./gdb/testsuite/gdb.threads/staticthreads.c against the glibc master in static
mode an old gdb does seems to get correct backtraces:

$ gdb ./tst-staticthreads
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
[...]
(gdb) b main
Breakpoint 1 at 0x103cc: file tst-staticthreads.c, line 36.
(gdb) r
[...]
(gdb) b __libc_do_syscall
[...]
(gdb) c
Continuing.
[...]
Breakpoint 2, __libc_do_syscall () at
../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:40
(gdb) thread apply all bt

Thread 2 (LWP 5282 "tst-staticthrea"):
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:40
#1  0x000153e4 in start_thread (arg=0x696c6720) at pthread_create.c:388
#2  0x0001f198 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone3.S:71
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (LWP 5277 "tst-staticthrea"):
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:40
#1  0x0003877a in __futex_abstimed_wait_common32 (private=<optimized out>,
cancel=<optimized out>, abstime=<optimized out>, op=<optimized out>,
expected=<optimized out>, futex_word=<optimized out>) at futex-internal.c:40
#2  __futex_abstimed_wait_common (futex_word=0xb6ffc808, expected=5282,
clockid=<optimized out>, abstime=<optimized out>, private=private@entry=128,
cancel=cancel@entry=true) at futex-internal.c:99
#3  0x0003884c in __futex_abstimed_wait_cancelable64 (futex_word=<optimized
out>, expected=<optimized out>, clockid=<optimized out>, abstime=<optimized
out>, private=private@entry=128) at futex-internal.c:139
#4  0x000163f6 in __pthread_clockjoin_ex (threadid=3070216096,
thread_return=thread_return@entry=0x0, clockid=clockid@entry=0,
abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:102
#5  0x00016338 in ___pthread_join (threadid=<optimized out>,
thread_return=thread_return@entry=0x0) at pthread_join.c:24
#6  0x0001041c in main (argc=<optimized out>, argv=<optimized out>) at
tst-staticthreads.c:54

So the unwind information seems to be correct from glibc side.

(I built with thumb enable to mimic what ubunut22 does).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
Since this is a static exec, can somebody attach the exec that demonstrates the
problematic behaviour?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #10 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Created attachment 15309
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15309&action=edit
Testcase executable from run where it failed.

Here's the executable.

Interestingly, when manually running it under GDB I was also able to backtrace
through __futex_abstimed_wait_common (after issuing "continue" a number of
times to find a thread with that function in the backtrace):

(gdb) thread apply all bt

Thread 2 (Thread 0xf7fee700 (LWP 2731853) "staticthreads"):
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x0001a920 in start_thread ()
#2  0x00043050 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x86000 (LWP 2731851) "staticthreads"):
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x000405ba in __futex_abstimed_wait_common ()
#2  0x00040688 in __futex_abstimed_wait_cancelable64 ()
#3  0x0001b96e in __pthread_clockjoin_ex ()
#4  0x0001b864 in pthread_join ()
#5  0x00010514 in main (argc=1, argv=0xfffef2a4) at
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:76

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #11 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
By the way, here's the gdb .log excerpt from the test run with the binary I
attached:

(gdb) PASS: gdb.threads/staticthreads.exp: thread 1
bt
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x000405ba in __futex_abstimed_wait_common ()
#2  0x00040688 in __futex_abstimed_wait_cancelable64 ()
#3  0x0001b96e in __pthread_clockjoin_ex ()
#4  0x0001b864 in pthread_join ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.threads/staticthreads.exp: bt
up 10
#4  0x0001b864 in pthread_join ()
(gdb) FAIL: gdb.threads/staticthreads.exp: up 10

So in this case GDB was able to unwind through __futex_abstimed_wait_common but
couldn't unwind through pthread_join.

Something else is going on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Thiago Jung Bauermann from comment #10)
> Created attachment 15309 [details]
> Testcase executable from run where it failed.
> 
> Here's the executable.
> 

Thanks.

[ One first observation is that on my platform, the static exec contains debug
info for both staticthreads.c and for pthreads.  The attached exec only has
debug info for staticthreads.c.  This causes the difference in detail in the
backtraces between say comment 2 and comment 11. ]

One thing I overlooked was that even with a static exec, there's still an
implicit dependency on libthread_db.  So when I used the attached exec, it
cannot load the local libthread_db because it's incompatible, so I can't print
tlsvar.

Otherwise, things appear to work as expected:
...
$ cat gdb.in
set pagination off
set trace-commands on
file /home/rock/gdb/staticthreads
break -qualified main
run
break 49
continue
thread 1
bt
up 10
$ gdb -q -batch -x gdb.in
+file /home/rock/gdb/staticthreads
+break -qualified main
Breakpoint 1 at 0x104a6: file
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c,
line 58.
+run

Breakpoint 1, main (argc=1, argv=0xfffef6d4) at
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:58
warning: 58    
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:
No such file or directory
+break 49
Breakpoint 2 at 0x10476: file
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c,
line 49.
+continue
[New LWP 13085]
[Switching to LWP 13085]

Thread 2 "staticthreads" hit Breakpoint 2, thread_function (arg=0x0) at
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:49
49      in
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c
+thread 1
[Switching to thread 1 (LWP 13083)]
#0  0x00010ab4 in __libc_do_syscall ()
+bt
#0  0x00010ab4 in __libc_do_syscall ()
#1  0x000405ba in __futex_abstimed_wait_common ()
#2  0x00040688 in __futex_abstimed_wait_cancelable64 ()
#3  0x0001b96e in __pthread_clockjoin_ex ()
#4  0x0001b864 in pthread_join ()
#5  0x00010514 in main (argc=1, argv=0xfffef6d4) at
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:76
+up 10
#5  0x00010514 in main (argc=1, argv=0xfffef6d4) at
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c:76
76      in
/home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.threads/staticthreads.c
...

I tried running this in a loop, always works fine.  So, unfortunately I can't
reproduce the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 15310
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15310&action=edit
gdb output log

The best thing I can think of doing is posting the output of this debug
session:
...
$ cat gdb.in
set pagination off
set trace-commands on
file /home/rock/gdb/staticthreads
break -qualified main
run
break 49
continue
thread 1
up 4
set debug frame on
up
$ gdb -q -batch -x gdb.in > log.txt 2>&1
...

Perhaps comparing with the debug frame info for a failing session will show a
relevant difference.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #14 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Created attachment 15325
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15325&action=edit
debug frame log - working backtrace

Thank you for the suggestion!

Here is the log file in an instance where everything works.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #15 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Created attachment 15326
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15326&action=edit
debug frame log - failing backtrace

And here is the log file from a session where it fails.

One thing I noticed while looking into this today is that if I comment out the
"arm exidx" unwinder, then I can't reproduce the problem anymore.

And indeed, looking at this failing backtrace it was used to unwind a few
frames, while in the good backtrace it wasn't used in any frame.

I'll dig more into this tomorrow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #16 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Bug #31294 has similar symptoms to this one. There's a chance it could be the
same bug.

I think there's a memory corruption issue with one of the data structures used
by the "arm exidx" unwinder:

arm_exidx_new_objfile () correctly extracts the unwind instructions from the
libc functions that are statically linked into staticthreads and stores them in
an arm_exidx_entry, but when arm_find_exidx_entry () finds the entry there is
garbage instead of the unwind instructions.

I'm hoping to have more information tomorrow.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #17 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
Created attachment 15347
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15347&action=edit
memcheck output of corruption problem

Valgrind pointed out what the problem is. I'm attaching the full output (the
line numbers may be a bit off due to some debug statements I added), but here
are the highlights:

As I mentioned in the previous comment, arm_find_exidx_entry () returns an
entry containing garbage. Then arm_exidx_fill_cache () reads it:

==3763513== Invalid read of size 1
==3763513==    at 0x3DE8CC: arm_exidx_fill_cache(frame_info_ptr, unsigned
char*) (arm-tdep.c:2865)
==3763513==    by 0x3DFFE1: arm_exidx_unwind_sniffer(frame_unwind const*,
frame_info_ptr, void**) (arm-tdep.c:3277)
==3763513==    by 0x6317ED: frame_unwind_try_unwinder(frame_info_ptr, void**,
frame_unwind const*) (frame-unwind.c:138)

The problem is that arm_exidx_new_objfile () stores the unwind instructions in
the objfile's obstack but it is freed before arm_exidx_fill_cache () has a
chance to use it:

==3763513==  Address 0xa128e10 is 608 bytes inside a block of size 4,072 free'd
==3763513==    at 0x4867A68: free (vg_replace_malloc.c:872)
==3763513==    by 0x374A3F: void xfree<void>(void*) (gdb-xfree.h:37)
==3763513==    by 0x518A351: obstack_free (obstack.c:357)
==3763513==    by 0x9A3B45: reread_symbols(int) (symfile.c:2587)
==3763513==    by 0x6C18CF: run_command_1(char const*, int, run_how)
(infcmd.c:398)
==3763513==    by 0x6C1CBB: run_command(char const*, int) (infcmd.c:512)

This happens because reread_symbols () detects that the staticthreads
executable has changed since it was loaded (I don't know why, though) and thus
reinitializes the objfile obstacks.

I'll see if I can make arm-tdep.c add a hook in objfiles_changed () so that it
can detect that the objfiles where reloaded and re-read the exception tables.
Or perhaps it's cleaner to convert objfiles_changed () into an observer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #18 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Thiago Jung Bauermann from comment #17)
> I'll see if I can make arm-tdep.c add a hook in objfiles_changed () so that
> it can detect that the objfiles where reloaded and re-read the exception
> tables. Or perhaps it's cleaner to convert objfiles_changed () into an
> observer.

I triggered the reread using "shell touch <file>" in the gdb script, and then
set a breakpoint on arm_exidx_new_objfile.  It triggered on the file command,
and on the reread at run command.  So I'm not sure this approach is necessary.

Perhaps we're looking at a regression since this commit:
...
commit a2726d4ff80168a8134c68cb798e3f5f537b0eba
Author: Luis Machado <luis.machado@linaro.org>
Date:   Thu Oct 31 16:30:44 2019 -0300

    [ARM] Store exception handling information per-bfd instead of per-objfile
...

I wonder if this fixes it:
...
diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index ecffb9223e1..4f68af75a4b 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -2704,7 +2704,7 @@ arm_exidx_new_objfile (struct objfile *objfile)
       if (n_bytes || n_words)
        {
          gdb_byte *p = entry
-           = (gdb_byte *) obstack_alloc (&objfile->objfile_obstack,
+           = (gdb_byte *) obstack_alloc (&objfile->per_bfd->storage_obstack,
                                          n_bytes + n_words * 4 + 1);

          while (n_bytes--)
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[luis.machado at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #19 from Luis Machado <luis.machado at arm dot com> ---
Hmmm, that would make sense, given we're storing thing in the bfd as opposed to
the objfile. Certainly an oversight.

Unfortunately I don't have a 32-bit arm system to try this at the moment, but
the fix makes sense.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #20 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Tom de Vries from comment #18)
> (In reply to Thiago Jung Bauermann from comment #17)
> > I'll see if I can make arm-tdep.c add a hook in objfiles_changed () so that
> > it can detect that the objfiles where reloaded and re-read the exception
> > tables. Or perhaps it's cleaner to convert objfiles_changed () into an
> > observer.
> 
> I triggered the reread using "shell touch <file>" in the gdb script, and
> then set a breakpoint on arm_exidx_new_objfile.  It triggered on the file
> command, and on the reread at run command.  So I'm not sure this approach is
> necessary.

Thanks for checking.

> Perhaps we're looking at a regression since this commit:
> ...
> commit a2726d4ff80168a8134c68cb798e3f5f537b0eba
> Author: Luis Machado <luis.machado@linaro.org>
> Date:   Thu Oct 31 16:30:44 2019 -0300
> 
>     [ARM] Store exception handling information per-bfd instead of per-objfile
> ...
> 
> I wonder if this fixes it:
> ...
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index ecffb9223e1..4f68af75a4b 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -2704,7 +2704,7 @@ arm_exidx_new_objfile (struct objfile *objfile)
>        if (n_bytes || n_words)
>  	{
>  	  gdb_byte *p = entry
> -	    = (gdb_byte *) obstack_alloc (&objfile->objfile_obstack,
> +	    = (gdb_byte *) obstack_alloc (&objfile->per_bfd->storage_obstack,
>  					  n_bytes + n_words * 4 + 1);
>  
>  	  while (n_bytes--)
> ...

Indeed it does! I was previously reproducing the problem in the first few
tries.
The loop has been running the testcase for more than 200 times now and it
always passes.

Thank you for the patch! Will you post it on the mailing list?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[tdevries at suse dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #21 from tdevries at suse dot de ---
On 2/1/24 19:32, thiago.bauermann at linaro dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=31254
> 
> --- Comment #20 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
> (In reply to Tom de Vries from comment #18)
>> (In reply to Thiago Jung Bauermann from comment #17)
>>> I'll see if I can make arm-tdep.c add a hook in objfiles_changed () so that
>>> it can detect that the objfiles where reloaded and re-read the exception
>>> tables. Or perhaps it's cleaner to convert objfiles_changed () into an
>>> observer.
>>
>> I triggered the reread using "shell touch <file>" in the gdb script, and
>> then set a breakpoint on arm_exidx_new_objfile.  It triggered on the file
>> command, and on the reread at run command.  So I'm not sure this approach is
>> necessary.
> 
> Thanks for checking.
> 
>> Perhaps we're looking at a regression since this commit:
>> ...
>> commit a2726d4ff80168a8134c68cb798e3f5f537b0eba
>> Author: Luis Machado <luis.machado@linaro.org>
>> Date:   Thu Oct 31 16:30:44 2019 -0300
>>
>>      [ARM] Store exception handling information per-bfd instead of per-objfile
>> ...
>>
>> I wonder if this fixes it:
>> ...
>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
>> index ecffb9223e1..4f68af75a4b 100644
>> --- a/gdb/arm-tdep.c
>> +++ b/gdb/arm-tdep.c
>> @@ -2704,7 +2704,7 @@ arm_exidx_new_objfile (struct objfile *objfile)
>>         if (n_bytes || n_words)
>>   	{
>>   	  gdb_byte *p = entry
>> -	    = (gdb_byte *) obstack_alloc (&objfile->objfile_obstack,
>> +	    = (gdb_byte *) obstack_alloc (&objfile->per_bfd->storage_obstack,
>>   					  n_bytes + n_words * 4 + 1);
>>   
>>   	  while (n_bytes--)
>> ...
> 
> Indeed it does! I was previously reproducing the problem in the first few
> tries.
> The loop has been running the testcase for more than 200 times now and it
> always passes.
> 
> Thank you for the patch! Will you post it on the mailing list?
> 

I could look into that starting say, Monday (attending FOSDEM), but if 
you can't wait that long feel free to submit.

Thanks,
- Tom

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #22 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to tdevries from comment #21)
> > Thank you for the patch! Will you post it on the mailing list?
> 
> I could look into that starting say, Monday (attending FOSDEM), but if 
> you can't wait that long feel free to submit.

No problem, it can wait. Enjoy FOSDEM!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[thiago.bauermann at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #23 from Thiago Jung Bauermann <thiago.bauermann at linaro dot org> ---
(In reply to Thiago Jung Bauermann from comment #17)
> ... reread_symbols () detects that the staticthreads
> executable has changed since it was loaded (I don't know why, though)

I found out why: Luis had fixed a discrepancy between the system header's
64-bit time_t and BFD's 32-bit one, but the fixed was accidentally disabled.

I posted a patch to re-enable it here:

https://inbox.sourceware.org/gdb-patches/20240203031408.137939-1-thiago.bauermann@linaro.org/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #24 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Thiago Jung Bauermann from comment #22)
> (In reply to tdevries from comment #21)
> > > Thank you for the patch! Will you post it on the mailing list?
> > 
> > I could look into that starting say, Monday (attending FOSDEM), but if 
> > you can't wait that long feel free to submit.
> 
> No problem, it can wait. Enjoy FOSDEM!

I did, thanks :)

Submitted:
https://sourceware.org/pipermail/gdb-patches/2024-February/206345.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/31254] [gdb, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #25 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bae2a57f4c07f46093e7bf00fec2554868e77189

commit bae2a57f4c07f46093e7bf00fec2554868e77189
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Feb 5 11:04:06 2024 +0100

    [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache

    On arm-linux the linaro CI occasionally reports:
    ...
     (gdb) up 10
     #4  0x0001b864 in pthread_join ()
     (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
    ...
    while this is expected:
    ...
     (gdb) up 10
     #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
     76          pthread_join (thread, NULL);
     (gdb) PASS: gdb.threads/staticthreads.exp: up 10
    ...

    Thiago investigated the problem, and using valgrind found an invalid read
in
    arm_exidx_fill_cache.

    The problem happens as follows:
    - an objfile and corresponding per_bfd are allocated
    - some memory is allocated in arm_exidx_new_objfile using
      objfile->objfile_obstack, for the "exception table entry cache".
    - a symbol reread is triggered, and the objfile, including the
      objfile_obstack, is destroyed
    - a new objfile is allocated, using the same per_bfd
    - again arm_exidx_new_objfile is called, but since the same per_bfd is
used,
      it doesn't allocate any new memory for the "exception table entry cache".
    - the "exception table entry cache" is accessed by arm_exidx_fill_cache,
      and we have a use-after-free.

    This is a regression since commit a2726d4ff80 ("[ARM] Store exception
handling
    information per-bfd instead of per-objfile"), which changed the "exception
    table entry cache" from per-objfile to per-bfd, but failed to update the
    obstack_alloc.

    Fix this by using objfile->per_bfd->storage_obstack instead of
    objfile->objfile_obstack.

    I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
    fixes it.

    Tested on arm-linux.

    Approved-By: Luis Machado <luis.machado@arm.com>

    PR tdep/31254
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31254] [gdb/tdep, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
            Summary|[gdb, arm] FAIL:            |[gdb/tdep, arm] FAIL:
                   |gdb.threads/staticthreads.e |gdb.threads/staticthreads.e
                   |xp: up 10                   |xp: up 10
         Resolution|---                         |FIXED
          Component|gdb                         |tdep
   Target Milestone|---                         |15.1

--- Comment #26 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31254] [gdb/tdep, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #27 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The gdb-14-branch-fixes branch has been updated by Thiago Bauermann
<bauermann@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7c709b26ba131f2a978aca373df6467a43510d28

commit 7c709b26ba131f2a978aca373df6467a43510d28
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Feb 5 11:04:06 2024 +0100

    [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache

    On arm-linux the linaro CI occasionally reports:
    ...
     (gdb) up 10
     #4  0x0001b864 in pthread_join ()
     (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
    ...
    while this is expected:
    ...
     (gdb) up 10
     #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
     76          pthread_join (thread, NULL);
     (gdb) PASS: gdb.threads/staticthreads.exp: up 10
    ...

    Thiago investigated the problem, and using valgrind found an invalid read
in
    arm_exidx_fill_cache.

    The problem happens as follows:
    - an objfile and corresponding per_bfd are allocated
    - some memory is allocated in arm_exidx_new_objfile using
      objfile->objfile_obstack, for the "exception table entry cache".
    - a symbol reread is triggered, and the objfile, including the
      objfile_obstack, is destroyed
    - a new objfile is allocated, using the same per_bfd
    - again arm_exidx_new_objfile is called, but since the same per_bfd is
used,
      it doesn't allocate any new memory for the "exception table entry cache".
    - the "exception table entry cache" is accessed by arm_exidx_fill_cache,
      and we have a use-after-free.

    This is a regression since commit a2726d4ff80 ("[ARM] Store exception
handling
    information per-bfd instead of per-objfile"), which changed the "exception
    table entry cache" from per-objfile to per-bfd, but failed to update the
    obstack_alloc.

    Fix this by using objfile->per_bfd->storage_obstack instead of
    objfile->objfile_obstack.

    I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
    fixes it.

    Tested on arm-linux.

    Approved-By: Luis Machado <luis.machado@arm.com>

    PR tdep/31254
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31254] [gdb/tdep, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

--- Comment #28 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The gdb-14-branch branch has been updated by Thiago Bauermann
<bauermann@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7c709b26ba131f2a978aca373df6467a43510d28

commit 7c709b26ba131f2a978aca373df6467a43510d28
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Feb 5 11:04:06 2024 +0100

    [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache

    On arm-linux the linaro CI occasionally reports:
    ...
     (gdb) up 10
     #4  0x0001b864 in pthread_join ()
     (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
    ...
    while this is expected:
    ...
     (gdb) up 10
     #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
     76          pthread_join (thread, NULL);
     (gdb) PASS: gdb.threads/staticthreads.exp: up 10
    ...

    Thiago investigated the problem, and using valgrind found an invalid read
in
    arm_exidx_fill_cache.

    The problem happens as follows:
    - an objfile and corresponding per_bfd are allocated
    - some memory is allocated in arm_exidx_new_objfile using
      objfile->objfile_obstack, for the "exception table entry cache".
    - a symbol reread is triggered, and the objfile, including the
      objfile_obstack, is destroyed
    - a new objfile is allocated, using the same per_bfd
    - again arm_exidx_new_objfile is called, but since the same per_bfd is
used,
      it doesn't allocate any new memory for the "exception table entry cache".
    - the "exception table entry cache" is accessed by arm_exidx_fill_cache,
      and we have a use-after-free.

    This is a regression since commit a2726d4ff80 ("[ARM] Store exception
handling
    information per-bfd instead of per-objfile"), which changed the "exception
    table entry cache" from per-objfile to per-bfd, but failed to update the
    obstack_alloc.

    Fix this by using objfile->per_bfd->storage_obstack instead of
    objfile->objfile_obstack.

    I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
    fixes it.

    Tested on arm-linux.

    Approved-By: Luis Machado <luis.machado@arm.com>

    PR tdep/31254
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tdep/31254] [gdb/tdep, arm] FAIL: gdb.threads/staticthreads.exp: up 10

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|15.1                        |14.2

-- 
You are receiving this mail because:
You are on the CC list for the bug.