Segfault while checking for suffix of executables

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Segfault while checking for suffix of executables

Strates, Jimmy
Hello Autoconf maintainers,

I seem to have an issue with my computer; this almost positively isn’t a bug in autoconf, but I can’t find the source.

I am using a Mac and installing packages through MacPorts; the other day, every package that used an autoconf configure script started segfaulting while “checking for suffix of executables…”. I’ve completely uninstalled everything in MacPorts and MacPorts, reinstalled MacPorts, and the problem persists.

I downloaded the autoconf 2.69 tarball (MacPorts is using autoconf 2.69) and ran the test suite with the MacPorts autoconf. The results were concerning…

[GNU Autoconf 2.69] testsuite: 1 24 226 232 233 263 264 267 268 269 270 271 272 273 274 275 276 277 278 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 306 307 308 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 349 351 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 374 376 379 380 382 384 385 386 387 388 390 393 394 395 396 397 398 399 400 404 405 407 408 410 411 413 414 415 416 417 419 421 423 424 425 426 429 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 failed

I had similar results from building from the tarball source and testing its build output. the testsuite.log is attached

I would greatly appreciate if you would help me understand what is happening during the “checking for suffix of executables" step so that I may find the underlying issue. It seems to be a rather fundamental issue but I just don’t have the background knowledge to find it.

Thanks,
Jimmy Strates


testsuite.log (321K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Segfault while checking for suffix of executables

Eric Blake-3
On 08/29/2017 11:17 AM, Strates, Jimmy wrote:
>
> I seem to have an issue with my computer; this almost positively isn’t a bug in autoconf, but I can’t find the source.
>
> I am using a Mac and installing packages through MacPorts; the other day, every package that used an autoconf configure script started segfaulting while “checking for suffix of executables…”. I’ve completely uninstalled everything in MacPorts and MacPorts, reinstalled MacPorts, and the problem persists.
>
> I downloaded the autoconf 2.69 tarball (MacPorts is using autoconf 2.69) and ran the test suite with the MacPorts autoconf. The results were concerning…

Let's look at some of those failures:

> ## ---------------------- ##
> ## Detailed failed tests. ##
> ## ---------------------- ##
>
> #                             -*- compilation -*-
> 1. tools.at:46: testing Syntax of the shell scripts ...
> ./tools.at:48: test "$ac_cv_sh_n_works" = yes || exit 77
> ./tools.at:53: /bin/sh -n "$abs_top_builddir/bin/autoconf"
> stderr:
> ./tools.at:54: /bin/sh -n "$abs_top_builddir/tests/autoconf"
> stderr:
> /bin/sh: can't open input file: /tmp/autoconf-2.69/tests/autoconf
> ./tools.at:54: exit code was 127, expected 0
> 1. tools.at:46: 1. Syntax of the shell scripts (tools.at:46): FAILED (tools.at:54)
This says your system was unable to run a shell script that should have
just been created.

>
> #                             -*- compilation -*-
> 24. tools.at:879: testing autoupdating AU_ALIAS ...
> ./tools.at:892: autoupdate
> ./tools.at:893: autoconf --force
> ./tools.at:893: /bin/sh -n configure
> stderr:
> ./tools.at:893: exit code was 139, expected 0
> 24. tools.at:879: 24. autoupdating AU_ALIAS (tools.at:879): FAILED (tools.at:893)

Even more worrisome, this says /bin/sh dumped core when trying to
analyze whether a 'configure' script had any syntax errors.  Are you
sure you haven't corrupted /bin/sh?  If you can't trust /bin/sh to not
dump core, there's not much autoconf can do; conversely, if we can
isolate exactly what bug we are tickling in /bin/sh, it may be possible
to tweak autoconf to avoid generating shell scripts that tickle that
pattern.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


signature.asc (632 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Segfault while checking for suffix of executables

Strates, Jimmy
Fixed!

Installing bash from MacPorts and symlinking to /bin/sh fixed the issue

Something messed up the preinstalled Mac framework a couple months ago (likely something like symlinking in a macports version of a library, though I don’t actually do that and I don’t know what I did). I’ve run into a couple issues like this, but /bin/bash not working correctly is by far the most pernicious.

Thanks for the quick response, Eric… saved me a lot of hassle

Jimmy


> On Aug 29, 2017, at 12:39 PM, Eric Blake <[hidden email]> wrote:
>
> On 08/29/2017 11:17 AM, Strates, Jimmy wrote:
>>
>> I seem to have an issue with my computer; this almost positively isn’t a bug in autoconf, but I can’t find the source.
>>
>> I am using a Mac and installing packages through MacPorts; the other day, every package that used an autoconf configure script started segfaulting while “checking for suffix of executables…”. I’ve completely uninstalled everything in MacPorts and MacPorts, reinstalled MacPorts, and the problem persists.
>>
>> I downloaded the autoconf 2.69 tarball (MacPorts is using autoconf 2.69) and ran the test suite with the MacPorts autoconf. The results were concerning…
>
> Let's look at some of those failures:
>
>> ## ---------------------- ##
>> ## Detailed failed tests. ##
>> ## ---------------------- ##
>>
>> #                             -*- compilation -*-
>> 1. tools.at:46: testing Syntax of the shell scripts ...
>> ./tools.at:48: test "$ac_cv_sh_n_works" = yes || exit 77
>> ./tools.at:53: /bin/sh -n "$abs_top_builddir/bin/autoconf"
>> stderr:
>> ./tools.at:54: /bin/sh -n "$abs_top_builddir/tests/autoconf"
>> stderr:
>> /bin/sh: can't open input file: /tmp/autoconf-2.69/tests/autoconf
>> ./tools.at:54: exit code was 127, expected 0
>> 1. tools.at:46: 1. Syntax of the shell scripts (tools.at:46): FAILED (tools.at:54)
>
> This says your system was unable to run a shell script that should have
> just been created.
>
>>
>> #                             -*- compilation -*-
>> 24. tools.at:879: testing autoupdating AU_ALIAS ...
>> ./tools.at:892: autoupdate
>> ./tools.at:893: autoconf --force
>> ./tools.at:893: /bin/sh -n configure
>> stderr:
>> ./tools.at:893: exit code was 139, expected 0
>> 24. tools.at:879: 24. autoupdating AU_ALIAS (tools.at:879): FAILED (tools.at:893)
>
> Even more worrisome, this says /bin/sh dumped core when trying to
> analyze whether a 'configure' script had any syntax errors.  Are you
> sure you haven't corrupted /bin/sh?  If you can't trust /bin/sh to not
> dump core, there's not much autoconf can do; conversely, if we can
> isolate exactly what bug we are tickling in /bin/sh, it may be possible
> to tweak autoconf to avoid generating shell scripts that tickle that
> pattern.
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>


signature.asc (859 bytes) Download Attachment